Re: Redisplay hook

[Clément Pit--Claudel]

On 2016-07-04 10:47, Eli Zaretskii wrote:
> redisplay-end-trigger functions are not exactly what you need in this
> context anyway (...)

Agreed; thanks for the details

> The main problem is that "end of redisplay" is not well defined, and
> can have quite different meanings for different use cases.  That's
> because each redisplay cycle includes 2 distinct phases.  In the first
> phase, the display engine builds data structures, called "desired
> glyph matrices", which describe how the changed parts of the display
> should look.  In the second phase, it actually updates the screen by
> comparing the desired glyph matrices with the current glyph matrices
> (the latter describe how the screen looks now), and writing to the
> glass in the portions where the 2 sets of matrices differ.

Thanks for taking the time to explain all of this.

> Some use cases want to run the hook after the first phase, some (like
> yours) after the second.  Moreover, redisplay can sometimes be
> preempted half-way through (e.g., if some input arrives), in which
> case it aborts the current cycle and doesn't update the screen.  For
> some use cases, this means redisplay never happened, for others it did
> (because some of the display code was run, and the corresponding side
> effects happened, e.g., the fontification functions were called).  On
> top of that, some legitimate use cases may wish to be able to abort
> the redisplay cycle under some conditions.  Finally, the 2nd phase of
> redisplay on GUI frames works by updating each window of the frame's
> window tree separately, whereas text-mode frames are updated by first
> building the frame-level desired glyph matrix, and then updating the
> frame as a whole.  So hooks which are interested in only some windows
> (e.g., the selected window) should be invoked differently for
> different frame types.

Ok. This is pretty involved :)

> The upshot of all this is that IMO if we decide to provide the
> post-redisplay hook, we will need to figure out all of these use
> cases, and perhaps provide separate hooks for some of them; otherwise,
> I'm quite sure that soon enough someone files a bug report or posts a
> message here complaining that the existing hooks don't work for
> them...

Yes, that makes a lot of sense.  On the other hand, we don't need to implement 
all of this at once.  As long as we're fairly sure that we understand the use 
cases well, we might be able to implement the parts that there is immediate 
demand for, leaving room for future extensions as needed. 

> Volunteers are welcome, as always.  Perhaps a useful first step would
> be to collect the relevant use cases, filter out the non-relevant
> ones, and then to classify the rest in some useful manner.

Ok. I'll start a new thread for this.

Clément.

signature.asc
Description: OpenPGP digital signature