bug#22404: 25.1.50; Forcing `window-scroll-functions` to run.

[Keith David Bershatsky]

A forced redisplay every command loop would pose two (2) major problems as far 
as I am aware.  The first issue will be that an unfinished display will be 
visible to the user for a split second before it gets finished with whatever 
code follows the first visible redisplay -- this will be especially visible 
when moving to an entirely different location of the buffer (e.g., full screen 
up or full screen down).  The second issue will be a significant slow-down in 
performance that will be mostly visible to the user when using rapid-fire 
keystrokes, or simply moving the cursor with the arrow keys by holding the 
arrow key in any of the four directions.  A forced redisplay is something that 
should be used sparingly, but not every command loop.

The four (4) values I seek *may* be available via Lisp depending upon where the 
`post-redisplay-hook` is placed.  I'd be happy to run some tests once you have 
decided upon a proposed location for the hook.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Tue, 02 Feb 2016 18:34:58 +0200,
Eli Zaretskii wrote:
> 
> > Date:  Mon, 01 Feb 2016 05:18:02 -0800
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  22404@debbugs.gnu.org
> > 
> > The four (4) values that I am most interested in are:
> > 
> >   1.  window-start
> > 
> >   2.  window-end
> > 
> >   3.  Point at the beginning of the line containing window-start.
> > 
> >   4.  Point at the end of the line containing window-end.
> 
> These are available from Lisp, so there seems to be no need to pass
> them as arguments to the hook, right?
> 
> > Although my proposed usage of the `post-redisplay-hook` will not be to 
> > alter buffer (i.e., I'm just adding overlays), other people who may use 
> > this new hook in the future may be modifying the buffer content -- e.g., 
> > adding/removing fonts, adding/removing text, moving the cursor, etc.
> 
> If those users need this new hook, they can always invoke redisplay
> explicitly at the end of their code, right?
> 
> > The `window-scroll-functions` hook is strategically placed at three 
> > locations of `xdisp.c`, and some of those areas are revisited when things 
> > have changed since the first pass -- e.g., continuation line at the 
> > beginning of the window, or cursor is partially visible at the bottom of 
> > the window.
> 
> But the fact they run in the middle of the redisplay cycle is exactly
> the source of the problems we are trying to solve!
> 
> > If the `post-redisplay-hook` runs too late in time to receive any checks 
> > regarding cursor position and so forth, some users may be surprised when 
> > their cursor ends up below the visible screen at the conclusion of 
> > redisplay -- e.g., because they added text or increased a font size that 
> > pushed the cursor further down below.
> 
> Calling redisplay explicitly should resolve all those issues.