Re: emacs-27 d7a4cea: ; Add a new item to TODO

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 17 Dec 2020 11:22:49 -0500
> 
> > +** Make redisplay smarter about which parts to redraw
> > +Currently, redisplay has only 2 levels of redrawing: either it
> > +redisplays only the selected window on the selected frame, or it
> > +redisplays all the windows on all the frames.  This doesn't scale well
> > +when the number of visible frames is large.
> 
> I don't think that's true: the change I installed some years back (along
> with the `pre-redisplay-function` and its use for the region highlight)
> does specifically try and select a particular subset of frames/windows.
> That's what the `wset_redisplay`, `fset_redisplay` and `bset_redisplay`
> are about.

See bug#42406.

My personal experience is that fset_redisplay and wset_redisplay are
not "strong" enough to cause redisplay in many situations, so we need
to use those 2 variables to enforce more thorough redisplay.  In
particular, there are the cases where elements of display may need to
be redrawn that don't belong to any window.

> > +Currently, two variables are used to make the decision what to
> > +redisplay: update_mode_lines and windows_or_buffers_changed.
> 
> There's also a `redisplay` "bit" on frames, windows, and buffer
> text objects.

They are not very useful, and the problematic cases don't involve them
anyway.

> In order to make this easier I changed the code such that every
> assignment to those two variable sets it to a different value, and then
> in at every redisplay cycle are record which value is found by
> increasing the counter in the corresponding slot of
> `redisplay--all-windows-cause` and `redisplay--mode-lines-cause`.

That's useful when debugging excess redisplays, and can also help in
analyzing the use cases to decide on the bits.  But we need to go
further than that, IMO, because the current logic is still quite
simplistic.