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

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

>> > Not necessarily: there are the w->optional_new_start and
>> > w-> force_start flags, which determine what redisplay does with
>> > window-start in these cases.
>> > Also, the window-start could be set to a value that leaves point out
>> > of the displayed area, in which case it won't be in effect.
>> Right, but these fall back into the case where redisplay performs
>> a second pass trough the window/buffer, so it's similar to the scrolling
>> case, right?
> Not necessarily, AFAIR.  Sometimes these situations are detected and
> handled on the fly.

Aha!  Could you add comment somewhere in xdisp.c discussing the above
issues about how/when is window-start obeyed and when it's not and
when that causes a second pass and when that's handled on the fly?
It doesn't have to be exhaustive, but at least mentioning the known
cases, and ideally pointing to the corresponding code.

>> Ah, right, I forgot about this.  So maybe window-scroll-functions is the
>> answer to the OP's needs!
> Or maybe we should call them in more places during redisplay.

Could be.  But I already find it hard to know what can be done with
window-scroll-functions because it's not clear exactly when it's called,
in 2 sense:
- it's not clear exactly when it is called and when it is not.
- it's not clear exactly at which stage of redisplay it is called
  (e.g. what has already been processed, what hasn't; will any and all
  modifications caused by window-scroll-functions be reflected on screen
  at the end of the current redisplay, or will some of it only be
  handled by the next redisplay?  If so, which do and which don't?)


-- Stefan