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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> 1- decide which windows may need to be updated.
>
> More accurately:
>
>   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.

AFAICT the main place where we check a frame's `redisplay` bit is in
`needs_no_redisplay` which operates on a window.

In most cases a frame's `redisplay` bit should not be set, tho some of
its windows' `redisplay` bits may be set, and we will consider this
frame and all its windows (to find those that need to be updated).

>> BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
>> redisplay could be moved to ELisp.  This would allow for example
>> `follow-mode` to pick a more appropriate order in which to process the
>> windows at step 2.
>
> follow-mode needs much more than that.

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.

I guess we could try to "save the redisplay bit" of other
windows/buffers/frames, and restore them afterwards.  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).


        Stefan