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

[Keith David Bershatsky <esq@lawlist.com>]

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.