Re: Redisplay hook

[Eli Zaretskii]

> Cc: address@hidden
> From: Clément Pit--Claudel <address@hidden>
> Date: Mon, 4 Jul 2016 00:31:15 -0400
> 
> > But before we discuss this seriously, I have a feeling that such a
> > hook was already discussed in the past, and we found it unnecessary
> > and/or dangerous.  Stefan, do you remember something like that?
> 
> Thanks.  My search-engine-fu was insufficient to dig up that discussion.  It 
> could be around the time of the commit below, but none of Stefan's posts at 
> the 
> time mention that
> 
>     commit 379ec02c03febd0955b2c235c9e596db82fef8a0
>     Author: Stefan Monnier <address@hidden>
>     Date:   Tue Mar 25 17:32:20 2008 +0000
> 
>         (redisplay-end-trigger-functions, window-redisplay-end-trigger)
>         (set-window-redisplay-end-trigger, process-filter-multibyte-p)
>         (set-process-filter-multibyte): Mark as obsolete.

redisplay-end-trigger functions are not exactly what you need in this
context anyway: these functions are only called when the display
engine finishes to examine the specified buffer position.  So their
assumed use case is different from yours, and I'm quite sure they are
not easy to use in practice if the buffer position where they should
be invoked is indeed important (because knowing in advance when that
position will be traversed by the display engine requires an
unrealistically good knowledge of how the display engine works, and is
non-trivial even then).

> Further digging points to:
> 
> - https://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00785.html, in 
> which Stefan mentioned a post-redisplay-hook in passing
> 
> - https://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01313.html, which 
> Alan started, and in which you mentioned 
> (https://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01428.html) such a 
> hook.
> 
> - https://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00785.html, 
> where 
> Stefan asked for a pre-redisplay-hook, and Richard expressed concerns about 
> debugging display-related hooks.
> 
> - https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-01/msg01011.html, 
> where 
> you mentioned maybe needing a post-redisplay-hook.

Thanks.  Let me explain why this issue is not so simple.

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.

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.

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

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.