GNU bug report logs - #32839
27.0.50; recenter doesn't redisplay

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 32839 <at> debbugs.gnu.org
Subject: bug#32839: 27.0.50; recenter doesn't redisplay
Date: Sun, 30 Sep 2018 09:22:11 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 32839 <at> debbugs.gnu.org
> Date: Sun, 30 Sep 2018 02:38:03 +0300
> 
> >   List of functions to call before redisplaying a window with scrolling.
> >                                                          ^^^^^^^^^^^^^^
> 
> But (info "(emacs) Recentering") says that recentering is scrolling:
> 
>      Typing ‘C-l’ twice in a row (‘C-l C-l’) scrolls the window so that
>                                              ^^^^^^^
>   point is on the topmost screen line.  Typing a third ‘C-l’ scrolls the
>                                                              ^^^^^^^
>   window so that point is on the bottom-most screen line.  Each successive
>   ‘C-l’ cycles through these three positions.

That's because C-l in most cases indeed scrolls, and I don't see a
point in making the documentation much more complicated due to this
special case.  But if you think it's important enough, we could come
up with some wording that would reflect the situation more accurately,
or say things more vaguely.

> So 'C-l C-l C-l' is eligible for the calls of window-scroll-functions.

It's eligible, but its eligibility doesn't always materialize.

Frankly, I'm not sure where this discussion goes.

> I grepped for window-scroll-functions, and see that the current situation
> is quite bad:
> 
> 1. tabulated-list-window-scroll-function is not called on 'C-u -1 C-l'
>    when the last window line is fully visible, so it doesn't adjust
>    the width for display-line-numbers in this case.

A bug report with a recipe would be appreciated.

> 2. linum-mode relies more on post-command-hook because
>    window-scroll-functions is not reliable.
> 
> 3. erc-scroll-to-bottom was forced to replace window-scroll-functions
>    with post-command-hook because window-scroll-functions doesn't
>    support altering the way the window is scrolled.

Like I said a few days ago: the hooks provided by the display engine
cannot possibly be as accurate as you expect, because the display
engine doesn't know enough about the application, and its main purpose
is to redraw the screen as cheaply as possible.  The correlation
between what the display engine does and higher-level concepts like
"scrolling" can be quite low in some cases, because "scrolling" means
something very different to the display engine than what it means to
users and Lisp programs.

> The only hope to fix these problems and to close this report is to call
> the new hook window-state-change-functions at the very end when the
> redisplay is completely finished

"Redisplay is completely finished" is not well defined.  Especially
since some (most?) hooks only care about a specific window, whereas
redisplay considers more than one window.

Moreover, what would be the purpose of such a hook?  It can tell
nothing about what was done to perform redisplay.  For example, if the
display engine decided that the single displayed window didn't need to
be redrawn at all, the "redisplay completely finished" hook will still
be called, yes?

> probably at the same time when post-command-hook is called.

That hook is not called from the display code.  But in any case, if
post-command-hook is what you want, just use it.  Why do we need
another hook at the same place?  It sounds redundant.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.