GNU bug report logs -
#17678
24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay
Previous Next
Full log
Message #68 received at 17678 <at> debbugs.gnu.org (full text, mbox):
>> 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
This bug report was last modified 11 years and 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.