GNU bug report logs - #64596
30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: yantar92 <at> posteo.net, 64596 <at> debbugs.gnu.org
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 <at> iro.umontreal.ca>
> Cc: yantar92 <at> posteo.net,  64596 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.