Re: Use cases for post-redisplay hooks

[Keith David Bershatsky]

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