bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay

[Stefan Monnier <monnier@iro.umontreal.ca>]

> In a stackoverflow thread regarding this issue, @Stefan suggested that
> I take a look at the `jit-lock-register`.  After combing through the
> code in `jit-lock.el` and trying some experiments, I believe that
> `jit-lock.el` is more suited to a situation when buffer *modification*
> occurs -- it is also suited for situations where one may wish to
> incrementially act upon an entire buffer in small chunks at a time to
> increase efficiency of avaialble resources.

Indeed, jit-lock is designed for features that depend on the buffer's
*contents* but not on things like the value of `point'.

> I believe that the solution may be to have a `sneak-preview-redisplay`
> whereby the *new* `window-start` and *new* `window-end` could be
> correctly calculated without the visual buffer actually
> being redisplayed.

Of course, there's a circularity problem, here: if you need window-start
(you can already compute window-end without an actual redisplay) in
order to then install things like text-properties properties and
overlays that affect the display, then those added properties may end up
requiring changing window-start again (because they end up pushing point
outside of the window and require a scroll).

This said, the request is reasonable, and seems related to the needs of
follow-mode as well.

IIUC your particular use case (drawing crosshairs to show where the
cursor is located) is one where what you really need is to know when
window-start changes (just like follow-mode).

So, a good feature might be one that runs a hook when redisplay decides
that window-start needs to be reset (i.e. that point moved out of the
window and we need to scroll).


        Stefan