Re: Use cases for post-redisplay hooks

[Keith David Bershatsky <esq@lawlist.com>]

I can explain it in layman's terms, but I'm not familiar enough with how redisplay works to describe in computer language what happens exactly.  [I'm a hobbyist / tinkerer, but do not have any formal training in programming.]

I saw that the `window-scroll-functions` hook (hereinafter "WSF") returned correct values for `window-start` and `window-end` in some circumstances, but not all.  I saw that the WSF had about two (2) occasions where it is forced to run with a built-in flag, so I borrowed that functionality.  The `window-start-end-hook' (hereinafter "WSEH") is kind of like the WSF on steroids.  Wherever the WSF would normally be called, the WSEH is also called.  I added one (2) additional location for the WSEH to deal with mouse wheel scrolling.  I throw the switch on the WSEH every command loop.  The WSEH has a check to see if point is fully visible, because that is when `window-start` and `window-end` will not likely change again (so long as the Lisp function attached to the WSEH doesn't alter those value
 s in any way).  When point is fully visible, then the function attached to the WSEH runs and my overlays are placed on the visible window.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Tue, 05 Jul 2016 04:12:30 -0400,
Stefan Monnier wrote:
> 
> > The implementation of the `window-start-end-hook` is probably easier to
> > explain with a diff, which is attached.
> 
> Hmm... my understanding of the redisplay code is sufficiently fuzzy that
> your patch doesn't actually tell me how it's supposed to work.
> More specifically the timing is unclear to me: the overlays you add from
> your hook affect the display, so you need to run (the bulk of) the
> redisplay code *after* running your hook.
> 
> So sounds more like a pre-redisplay-hook.  Except that you pre-compute
> the expected window-end somehow.
> 
> 
>         Stefan