Re: Use cases for post-redisplay hooks

[Stefan Monnier]

> Summarizing the current discussion:
>
> (1) Is still valid, though Richard did suggest that we could have Emacs take
> the screenshots itself. It would indeed be a useful feature to have, though
> it is partly orthogonal, and seems non-trivial to implement. Richard also
> suggested special casing this feature and implementing only that instead
> of a post-display-hook.
>
> (2) Does not sound like it would benefit significantly from such a hook (but
> I may have missed something).
>
> (3) Does not resolve to something concrete.

On a related note, there could be some use for some kind of
"post-redisplay-hook" in follow-mode.  But it wouldn't just be
`post-redisplay-hook': it would need some way to control also the order
in which windows are redisplayed, and it would have to be run "between
windows" (at the end of computing the new matrices for a window).

The way I imagine this could work is by turning "redisplay" into an
Elisp function which internally would use some lower-level C functions
such as `recompute-matrices-of-window', `update-display-for-window`,
`update-display-for-frame`, and `find-windows-needing-redisplay`.

There would also be a need to control what happens when point needs to
be moved, or when scrolling is needed.
E.g. recompute-matrices-of-window could signal an error of some sort if
point is not within the window, and then `redisplay' could react to such
an error by either moving point or calling `window-try-scrolling'
if/when applicable.


        Stefan