bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-upda


From: Eli Zaretskii
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Date: Sat, 15 Jul 2023 19:16:57 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yantar92@posteo.net,  64596@debbugs.gnu.org
> Date: Sat, 15 Jul 2023 12:01:50 -0400
> 
> > But what happens in reality is that the breaking changes are made, and
> > then the "guilty parties" disappear into thin air, or lose interest.
> > And we are left with a broken redisplay and an unfinished project.
> 
> I didn't disappear into thin air, did I?

Let's not make this too personal.  Suffice it to say that I saw more
than once or twice changes in these areas which caused subtle
redisplay problems several years later, and I did have to fix a few of
them.  So what I wrote is based on facts and actual experience.

> >> That's eactly what happened when I introduced the 3 `redisplay` bits
> >> above: it did introduce a few bugs, but overall it made the code
> >> more clear.
> > No, that's not "exactly" what happened.  Some of the bugs popped up
> > much later, among other things.  I agree that the added comments made
> > the situation better, but you know as well as I do that some of the
> > aspects of those variables are still somewhat mysterious: specifically
> > the meaning of windows_or_buffers_changed and update_mode_lines for
> > disabling optimizations and shortcuts.  Which is exactly the focus of
> > the current discussion.
> 
> Those aspects are not due to my changes.  If they are mysterious it's
> because the remained mysterious, i.e. because I did not change them.

Indeed.  The above wasn't written to accuse, but to convey the fact
that we are not yet where we want to be in this regard.

> This said, the meaning of those vars is clear, I think (they mean, that
> all the windows/modelines need to be updated).

Not entirely true, AFAIU.  For example, what does update_mode_lines
have to do with preparing the menu bar?

  static void
  prepare_menu_bars (void)
  {
    bool all_windows = windows_or_buffers_changed || update_mode_lines;
    bool some_windows = REDISPLAY_SOME_P ();

or a similar reference in update_menu_bar.

Or why redisplay_internal does this:

  consider_all_windows_p = (update_mode_lines
                            || windows_or_buffers_changed);

And a couple of more "questionable" uses of that variable.

> What still isn't clear at some places is the reason why they're set.

Yes, that too.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]