emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: emacs-27 d7a4cea: ; Add a new item to TODO
Date: Thu, 17 Dec 2020 12:51:09 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> > +** 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.

Thanks.

> 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.

I fully agree.  But the above paragraph you installed is factually
incorrect, so anyone who reads this TODO and wants to act on it will
start with an incorrect understanding of the problem at hand and may
even give up right away seeing code like `bset_redisplay` and thinking
that the problem has already been solved.

> 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.

No argument from me on that ;-)


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]