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

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

>> 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?
> I will see what I can do.
> Done in emacs-24 revision 117239.  Please see if it's good enough.

Looks great, thank you very much.

> I'm not sure I follow.  Redisplay, at the level we are talking, has no
> stages.  It goes through all the windows on every frame, and does for
> each window what it thinks has to be done in that window.  A process
> of redisplaying a window is done in one go, there are no stages or
> phases in it.

AFAIK window-scroll-functions (as well as jit-lock) is run in the
middle of redisplay redisplay, so they get to see "the inside" and so
they break the illusion that redisplay happens "in one go".

> The window-scroll-functions are called when redisplay
> thinks it will scroll the window in order to redisplay it.
> Which modifications in window-scroll-functions did you have in mind?

For example:
- if code in window-scroll-functions affects some data which affects
  the mode-line, will the mode-line correctly reflect the state after
  running window-scroll-functions?
- if code in window-scroll-functions affects some data which influences
  the display of other windows (e.g. adds overlays, changes
  window-start, you name it), will those changes be reflected in the
  other windows at the end of this redisplay cycle?
- if point needs to be changed by redisplay (because window-start was
  set far away), will window-scroll-functions see the "old" point value
  or the "new" point value?


-- Stefan