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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yantar92@posteo.net,  64596@debbugs.gnu.org
> Date: Thu, 13 Jul 2023 18:02:26 -0400
> 
> > Then I guess you or Ihor (or both) should try removing that line and
> > run with that for a while.
> 
> FWIW, I've been running without those two lines ever since I put this FIXME.

I'd be happier with the alternative I proposed, which you cite below.
Because bitter experience taught me that your, Stefan, usage patterns
evidently exclude some use cases, because bug reports pop up after
your similar changes where the display is not updated in some cases.
I'm sure the same is true for the usage patterns of anyone of us, so
doing this on a small number of systems is not enough.

> > Alternatively, maybe in the case of ALL non-nil the code should set
> > the prevent_redisplay_optimizations_p flag of all the buffers that are
> > displayed in some window, since some redisplay optimizations are not
> > eligible when the mode-line is about to be updated.
> 
> Any reason why the corresponding optimizations don't consult the
> `update_mode_lines` var (or the `update_mode_line` buffer flag), or
> maybe have redisplay start by propagating the `update_mode_line` buffer
> flag to `prevent_redisplay_optimizations_p`?

Once again, prevent_redisplay_optimizations_p is NOT (just) about
updating mode lines, it affects more optimizations.  There's also
windows_or_buffers_changed, which is even "stronger".  For example,
try_window_id checks the prevent_redisplay_optimizations_p flag and
punts if it is set, although that optimization method AFAIK has
nothing to do with redisplaying mode lines, it is only about updating
the text area.

It would be nice to analyze all those flags, make them more selective,
and understand/document better what optimizations and optional
processing are affected by each one of them.  It is a large and
somewhat ungrateful job, so if someone wants to do it by
systematically examining the situations where we set each one of those
flags and their effects on redisplay, I can offer my best help (though
I cannot afford doing this job myself).

Failing that, we could try disabling some portions of the code.  This
is not the best method of collecting such systematic information, IME,
certainly not if just a couple of people do that, because experience
teaches us that usage patterns differ wildly, and different
window-systems and different window managers sometimes have
significant effect on this stuff.  So if we want to use this
"phenomenological" approach, my suggestion is to allow disabling the
relevant parts of the display-related code at run time, controlled by
variables exposed to Lisp.  We already have a bunch of inhibit-*
variables that inhibit specific optimizations in xdisp.c; we could add
more.  Then we could set the defaults of these variables according to
our best understanding, and if and when redisplay problems are
reported, ask people to flip one or more of these inhibit-* variables
and see if the problems go away.

Again, this is not the best way, so if someone here is willing to do a
thorough job regarding this, I encourage him or her to take the first
way, although it is harder.  The advantage is that we will have a much
better understanding and documentation of these flags, and will
probably be able to improve the ad-hoc set of flags we have today and
make it easier to use and maintain.  (Ideally, these flags should be a
single bitmap with individual reasons representing the causes for
disabling optimizations, and each optimization should examine the bits
it cares about.)