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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yantar92@posteo.net,  64596@debbugs.gnu.org
> Date: Sun, 16 Jul 2023 12:44:08 -0400
> 
> >   1a - decide whether all the windows need to be considered, or just
> >        the selected window
> >   1b - if all the windows need to be considered, decide for each frame
> >        whether it needs to be considered, and if so, consider all of
> >        that frame's windows
> >
> > Considering a window can sometimes decide very quickly that the window
> > doesn't need to be redisplayed, but, as I mentioned elsewhere, when
> > its frame's redisplay flag is set, we never decide that, and the
> > frame's redisplay flag is what causes us to consider a frame in the
> > first place.
> 
> Hmm... I'm not sure why you're saying
> 
>     frame's redisplay flag is what causes us to consider a frame in the
>     first place.

Because fset_redisplay does this:

  void
  fset_redisplay (struct frame *f)
  {
    redisplay_other_windows ();
    f->redisplay = true;
  }

and redisplay_other_windows sets windows_or_buffers_changed, which
then causes consider_all_windows_p to be true upon the next redisplay
cycle:

  consider_all_windows_p = (update_mode_lines
			    || windows_or_buffers_changed);

> If the redisplay toplevel could be hacked in ELisp, follow-mode could
> call the `update-window-glyph-matrix` on the "main window" of its
> window-set first, then get the resulting window-end/start and use that
> to adjust/scroll its next/prev windows, and then call
> `update-window-glyph-matrix` on them, thus propagating the information
> in the right direction and avoiding unnecessary redisplay computations.
> 
> > But if you want to be able to tell redisplay "update only this window
> > and nothing else", I think it should be easy to accomplish by adding
> > a single function and no other changes: all you need is to call
> > 'redisplay' (which is already exposed) after setting the redisplay
> > flag of a single window.
> 
> That won't avoid redisplaying the other windows whose `redisplay` bits
> had been set already for other reasons.

Yes, it will: when a window is redisplayed by redisplay_window, its
redisplay flag is reset, and it will not be redisplayed during this
cycle.  So if you have a way to redisplay a single window, you can do
that in any order you want, one window at a time, and those windows
which you redisplayed in this way will not be redisplayed until the
next cycle.

As for update-window-glyph-matrix, I don't see why that would help,
because updating the matrix without calling update_window fairly soon
after that will not produce the effect that you want.

> I guess we could try to "save the redisplay bit" of other
> windows/buffers/frames, and restore them afterwards.

What for?

> Also, it would be good to be able to compute the glyph matrices of
> the various affected windows before we do the actual glass update
> (especially if we want to handle iteration where some part of the
> redisplay (e.g. jit-lock, evaluation of mode-lines and menu bars,
> point moving out of scope forcing a scroll, you name it) causes
> changes which require recomputing a glyph matrix we just computed).

Sounds like an unnecessary complication to me, and for some situations
I'm not even sure how you can handle them, unless you thoroughly
redesign the display code.

IOW, this is not just a matter of exposing a small number of functions
to Lisp, IMO.