bug#32839: 27.0.50; recenter doesn't redisplay

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

As noted in bug#32672, maybe this is a regression, possibly caused by bug#31325

0. emacs -Q

1. Eval:

(setq recenter-redisplay t)

(add-to-list 'window-scroll-functions
             (lambda (window display-start)
               (message "window-scroll-functions %S %S %S"
                        window (window-buffer window) display-start)))

2. Open *Messages* in adjacent window with 'C-h e'

3. Put point in *scratch* preferably not on the first line

4. Type 'C-l' (recenter-top-bottom) with different arguments, e.g.
   C-0 C-l
   C-1 C-l
   C-2 C-l
   etc.

The *Messages* buffer is not refreshed to show new logged messages
from the calls of the window-scroll-functions.

This means that C-l (recenter-top-bottom) doesn't redisplay the frame -
which is strange since it calls 'recenter' with non-nil arg REDISPLAY.
Only after switching to the *Messages* buffer with 'C-x o' it gets
redisplayed and all previously emitted messages appear in it.

5. Typein *scratch* again: C-l C-l C-l
   only when C-l puts point to the center of the window,
   the *Messages* buffer gets redisplayed (but then for some reason
   window-scroll-functions is not called in this case).

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 25 Sep 2018 22:11:59 +0300
> 
> 1. Eval:
> 
> (setq recenter-redisplay t)
> 
> (add-to-list 'window-scroll-functions
>              (lambda (window display-start)
>                (message "window-scroll-functions %S %S %S"
>                         window (window-buffer window) display-start)))
> 
> 2. Open *Messages* in adjacent window with 'C-h e'
> 
> 3. Put point in *scratch* preferably not on the first line
> 
> 4. Type 'C-l' (recenter-top-bottom) with different arguments, e.g.
>    C-0 C-l
>    C-1 C-l
>    C-2 C-l
>    etc.
> 
> The *Messages* buffer is not refreshed to show new logged messages
> from the calls of the window-scroll-functions.
> 
> This means that C-l (recenter-top-bottom) doesn't redisplay the frame -
> which is strange since it calls 'recenter' with non-nil arg REDISPLAY.

'recenter' doesn't redisplay the frame, it only redisplays the window
which you recenter.

> 5. Typein *scratch* again: C-l C-l C-l
>    only when C-l puts point to the center of the window,
>    the *Messages* buffer gets redisplayed (but then for some reason
>    window-scroll-functions is not called in this case).

That's a feature: you set recenter-redisplay to t, which causes a
complete redraw of the frame when you type C-l.  And
window-scroll-functions aren't called when the window is not scrolled.

Bottom line: I'm unsure what is a bug here, if any.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

>> 5. Typein *scratch* again: C-l C-l C-l
>>    only when C-l puts point to the center of the window,
>>    the *Messages* buffer gets redisplayed (but then for some reason
>>    window-scroll-functions is not called in this case).
>
> That's a feature: you set recenter-redisplay to t, which causes a
> complete redraw of the frame when you type C-l.

I thought that recenter-redisplay set to t, which causes a complete
redraw of the frame, should also redraw the *Messages* buffer.

> And window-scroll-functions aren't called when the window is
> not scrolled.

I see that the window is scrolled while typing C-l C-l C-l ...
(recenter-top-bottom).  I tried in the middle of a large buffer
like 'C-h C-t' (view-emacs-todo).

The first C-l puts the current line in the middle, refreshes
the *Message* buffer, and displays the message in the echo area.

The second C-l puts the current line at the top, DOESN'T refresh
the *Message* buffer, but displays the message in the echo area.

The third C-l puts the current line at the bottom, DOESN'T refresh
the *Message* buffer, and DOESN'T display the message in the echo area,
which means window-scroll-functions is not called at all in this case.

All three have a different effect.

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 32839@debbugs.gnu.org
> Date: Tue, 25 Sep 2018 23:55:15 +0300
> 
> >> 5. Typein *scratch* again: C-l C-l C-l
> >>    only when C-l puts point to the center of the window,
> >>    the *Messages* buffer gets redisplayed (but then for some reason
> >>    window-scroll-functions is not called in this case).
> >
> > That's a feature: you set recenter-redisplay to t, which causes a
> > complete redraw of the frame when you type C-l.
> 
> I thought that recenter-redisplay set to t, which causes a complete
> redraw of the frame, should also redraw the *Messages* buffer.

Only when you invoke 'recenter' with no arguments.

> > And window-scroll-functions aren't called when the window is
> > not scrolled.
> 
> I see that the window is scrolled while typing C-l C-l C-l ...
> (recenter-top-bottom).

My point was that C-l without arguments doesn't necessarily scroll.

When the window is scrolled, the hook is being called.  That's what I
see here.

> I tried in the middle of a large buffer
> like 'C-h C-t' (view-emacs-todo).
> 
> The first C-l puts the current line in the middle, refreshes
> the *Message* buffer, and displays the message in the echo area.
> 
> The second C-l puts the current line at the top, DOESN'T refresh
> the *Message* buffer, but displays the message in the echo area.
> 
> The third C-l puts the current line at the bottom, DOESN'T refresh
> the *Message* buffer, and DOESN'T display the message in the echo area,
> which means window-scroll-functions is not called at all in this case.
> 
> All three have a different effect.

Because each one calls 'recenter' with a different argument, or no
argument at all.  I see nothing unexpected in what you describe, FWIW.

You need to keep in mind that "scrolling" is well defined only for
scroll commands and functions (scroll-up, scroll-down, etc.).  For
other commands and functions that move the viewport in the buffer, it
is up to the display engine whether to apply a scroll-like redraw (in
which case window-scroll-functions will be called) or not.  I think
setting scroll-conservatively to a large value will make the display
engine scroll in many more situations, but even then C-l might not
always call window-scroll-functions.

Also, you are talking about 2 different functions -- 'recenter' and
'recenter-top-bottom' -- and that adds confusion to the discussion, so
maybe I misunderstood something you wanted to say.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

> Also, you are talking about 2 different functions -- 'recenter' and
> 'recenter-top-bottom' -- and that adds confusion to the discussion, so
> maybe I misunderstood something you wanted to say.

I wanted to say that I see two problems here:

1. recenter doesn't redraw the frame when it is called with
   a non-nil REDISPLAY argument.

   In `recenter-top-bottom', when `recenter-last-op' is `top',
   this gets called:

     (recenter this-scroll-margin t)

   When `this-scroll-margin' is 0, the actual call is:

     (recenter 0 t)

   Despite its REDISPLAY argument set to t, the frame is not redisplayed.

2. The second problem is that after the call to (recenter -1 t),
   window-scroll-functions is called only when recenter moves the current
   buffer line to the second-last window line (when the last window line is
   partially visible).  But when the last window line is fully visible,
   window-scroll-functions is not called after (recenter -1 t).

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 32839@debbugs.gnu.org
> Date: Thu, 27 Sep 2018 02:55:38 +0300
> 
> 1. recenter doesn't redraw the frame when it is called with
>    a non-nil REDISPLAY argument.
> 
>    In `recenter-top-bottom', when `recenter-last-op' is `top',
>    this gets called:
> 
>      (recenter this-scroll-margin t)
> 
>    When `this-scroll-margin' is 0, the actual call is:
> 
>      (recenter 0 t)
> 
>    Despite its REDISPLAY argument set to t, the frame is not redisplayed.

This is how 'recenter' is documented to behave:

  If ARG is omitted or nil, then recenter with point on the middle line
  of the selected window; if REDISPLAY & ‘recenter-redisplay’ are
  non-nil, also erase the entire frame and redraw it [...]

IOW, the frame is redrawn only when ARG is nil and REDISPLAY is
non-nil.

> 2. The second problem is that after the call to (recenter -1 t),
>    window-scroll-functions is called only when recenter moves the current
>    buffer line to the second-last window line (when the last window line is
>    partially visible).  But when the last window line is fully visible,
>    window-scroll-functions is not called after (recenter -1 t).

Depending on the exact dimensions of the window and the size of your
font, this can legitimately happen.

You see, the way 'recenter' works, it sets a couple of fields in the
window object which instruct the display engine to change the
window-start point.  The actual recentering happens during the very
next redisplay cycle, at which time the display engine sees these
fields and acts accordingly.  To redisplay a window, the display
engine has several methods at its disposal; starting with the cheapest
one, it attempts to find the first applicable one, and then uses it.
Only some of the methods are considered to use "scrolling", others
aren't.  So that's why window-scroll-functions might not be called
when the text was "scrolled" by 'recenter' and its derivatives.

Like I said: "scrolling" is only well-defined when you use the
scrolling functions and commands, like scroll-up, scroll-down-command,
etc.  It is not well-defined with other functions which move the
viewport, so window-scroll-functions may or may not be called when
those other functions are invoked.

Bottom line, I see no problem in the behavior described in this bug
report, and I think it should be closed.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

>>      (recenter 0 t)
>>
>>    Despite its REDISPLAY argument set to t, the frame is not redisplayed.
>
> This is how 'recenter' is documented to behave:
>
>   If ARG is omitted or nil, then recenter with point on the middle line
>   of the selected window; if REDISPLAY & ‘recenter-redisplay’ are
>   non-nil, also erase the entire frame and redraw it [...]
>
> IOW, the frame is redrawn only when ARG is nil and REDISPLAY is
> non-nil.

Then why REDISPLAY is non-nil, if it doesn't redisplay the frame?

I still don't understand the logic: `recenter-redisplay' is non-nil,
the arg REDISPLAY is non-nil, and yet no redisplay, this makes no sense
and looks like a bug.

Maybe the problem lies in the name of the new arg REDISPLAY -
from its current behavior a more correct name would be:
`recenter-redisplay-only-when-another-arg-is-nil'.

But such a long name indicates broken logic.  It would make sense
for a nil value of the REDISPLAY arg not to redisplay, and
for a non-nil - to redisplay, or to take a special value like

  (recenter 0 'force)

>> 2. The second problem is that after the call to (recenter -1 t),
>>    window-scroll-functions is called only when recenter moves the current
>>    buffer line to the second-last window line (when the last window line is
>>    partially visible).  But when the last window line is fully visible,
>>    window-scroll-functions is not called after (recenter -1 t).
>
> Depending on the exact dimensions of the window and the size of your
> font, this can legitimately happen.
>
> You see, the way 'recenter' works, it sets a couple of fields in the
> window object which instruct the display engine to change the
> window-start point.  The actual recentering happens during the very
> next redisplay cycle, at which time the display engine sees these
> fields and acts accordingly.  To redisplay a window, the display
> engine has several methods at its disposal; starting with the cheapest
> one, it attempts to find the first applicable one, and then uses it.
> Only some of the methods are considered to use "scrolling", others
> aren't.  So that's why window-scroll-functions might not be called
> when the text was "scrolled" by 'recenter' and its derivatives.

I thought that scrolling for the sake of window-scroll-functions
implies the changes in the value of window-start, i.e. when
an old value of window-start is not the same as its new value,
this guarantees the call of window-scroll-functions.

The docstring of window-scroll-functions says:

  These functions are called whenever the ‘window-start’ marker is modified,
  either to point into another buffer (e.g. via ‘set-window-buffer’) or another
  place in the same buffer.

(recenter -1 t) definitely modifies the value of window-start,
so it's expected that window-scroll-functions should be called.

Maybe it will be called in the new hook window-state-change-functions
proposed by Martin.

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 32839@debbugs.gnu.org
> Date: Fri, 28 Sep 2018 01:59:04 +0300
> 
> >>      (recenter 0 t)
> >>
> >>    Despite its REDISPLAY argument set to t, the frame is not redisplayed.
> >
> > This is how 'recenter' is documented to behave:
> >
> >   If ARG is omitted or nil, then recenter with point on the middle line
> >   of the selected window; if REDISPLAY & ‘recenter-redisplay’ are
> >   non-nil, also erase the entire frame and redraw it [...]
> >
> > IOW, the frame is redrawn only when ARG is nil and REDISPLAY is
> > non-nil.
> 
> Then why REDISPLAY is non-nil, if it doesn't redisplay the frame?

There's a long history to this, you may wish to use "git -L" and look
at the discussions/bug reports related to 'recenter'.

The short answer is that this arrangement (which is new in Emacs 27)
has its main goal to allow "C-l" to redraw the entire frame when the
user so desires (by default, only on TTY frames), while avoiding the
frame redraw in most, if not all, other situations, because redrawing
a frame causes flickering.  This flickering is caused by Lisp programs
calling 'recenter', directly or indirectly.

> I thought that scrolling for the sake of window-scroll-functions
> implies the changes in the value of window-start, i.e. when
> an old value of window-start is not the same as its new value,
> this guarantees the call of window-scroll-functions.

That'd cause window-scroll-functions to be called in too many
unrelated situations, because almost every redisplay cycle changes the
value of window-start.  E.g., consider goto-char or goto-line or even
C-s that finds the match off-screen.

> The docstring of window-scroll-functions says:
> 
>   These functions are called whenever the ‘window-start’ marker is modified,
>   either to point into another buffer (e.g. via ‘set-window-buffer’) or another
>   place in the same buffer.

You've omitted the first line of the doc string:

  List of functions to call before redisplaying a window with scrolling.
                                                         ^^^^^^^^^^^^^^
> Maybe it will be called in the new hook window-state-change-functions
> proposed by Martin.

I hope not.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

>> >>      (recenter 0 t)
>> >>
>> >>    Despite its REDISPLAY argument set to t, the frame is not redisplayed.
>> >
>> > This is how 'recenter' is documented to behave:
>> >
>> >   If ARG is omitted or nil, then recenter with point on the middle line
>> >   of the selected window; if REDISPLAY & ‘recenter-redisplay’ are
>> >   non-nil, also erase the entire frame and redraw it [...]
>> >
>> > IOW, the frame is redrawn only when ARG is nil and REDISPLAY is
>> > non-nil.
>>
>> Then why REDISPLAY is non-nil, if it doesn't redisplay the frame?
>
> There's a long history to this, you may wish to use "git -L" and look
> at the discussions/bug reports related to 'recenter'.
>
> The short answer is that this arrangement (which is new in Emacs 27)
> has its main goal to allow "C-l" to redraw the entire frame when the
> user so desires (by default, only on TTY frames), while avoiding the
> frame redraw in most, if not all, other situations, because redrawing
> a frame causes flickering.  This flickering is caused by Lisp programs
> calling 'recenter', directly or indirectly.

I see that before the recent changes, on a TTY 'C-l' and
all non-interactive calls of 'recenter' cleared the frame,
but now only interactive calls of 'recenter' redraw the frame.

OTOH, what I'm trying to achieve here is to allow C-l with a non-nil
argument to refresh the *Messages* buffer when recenter-redisplay is t.

An additional problem is that when 'recenter-positions' is customized
to not contain the keyword 'middle', then 'recenter-top-bottom' never
uses a nil arg of 'recenter', thus never redraws the frame.

But since redrawing a frame causes flickering, I'm not interested
in setting recenter-redisplay to t.  So I could implement more
fundamental changes for this only if you insist.

However, a minimal change that is needed here is to fix inconsistencies
in the recent changes: the argument name 'redisplay' is confusing -
it implies that it overrides the default value of recenter-redisplay
to force the redisplay.  A proper name would be 'interactive'.
There are dozens of commands already that use this naming convention.

diff --git a/lisp/window.el b/lisp/window.el
index 76de4207e7..584b25224c 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8759,17 +8759,19 @@ recenter-positions
   :version "23.2"
   :group 'windows)
 
-(defun recenter-top-bottom (&optional arg)
+(defun recenter-top-bottom (&optional arg interactive)
   "Move current buffer line to the specified window line.
 With no prefix argument, successive calls place point according
 to the cycling order defined by `recenter-positions'.
 
 A prefix argument is handled like `recenter':
  With numeric prefix ARG, move current line to window-line ARG.
- With plain `C-u', move current line to window center."
-  (interactive "P")
+ With plain `C-u', move current line to window center.
+
+Interactively, INTERACTIVE is non-nil and handled like in `recenter'."
+  (interactive "P\np")
   (cond
-   (arg (recenter arg t))                 ; Always respect ARG.
+   (arg (recenter arg interactive))     ; Always respect ARG.
    (t
     (setq recenter-last-op
 	  (if (eq this-command last-command)
@@ -8780,15 +8782,15 @@ recenter-top-bottom
 	   (min (max 0 scroll-margin)
 		(truncate (/ (window-body-height) 4.0)))))
       (cond ((eq recenter-last-op 'middle)
-	     (recenter nil t))
+	     (recenter nil interactive))
 	    ((eq recenter-last-op 'top)
-	     (recenter this-scroll-margin t))
+	     (recenter this-scroll-margin interactive))
 	    ((eq recenter-last-op 'bottom)
-	     (recenter (- -1 this-scroll-margin) t))
+	     (recenter (- -1 this-scroll-margin) interactive))
 	    ((integerp recenter-last-op)
-	     (recenter recenter-last-op t))
+	     (recenter recenter-last-op interactive))
 	    ((floatp recenter-last-op)
-	     (recenter (round (* recenter-last-op (window-height))) t)))))))
+	     (recenter (round (* recenter-last-op (window-height))) interactive)))))))
 
 (define-key global-map [?\C-l] 'recenter-top-bottom)
 
diff --git a/src/window.c b/src/window.c
index 6cdc52f90e..dd8c221308 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5944,16 +5944,16 @@ relative to the selected window.  If ARG is negative, it counts up from the
 bottom of the window.  (ARG should be less than the height of the window.)
 
 If ARG is omitted or nil, then recenter with point on the middle line
-of the selected window; if REDISPLAY & `recenter-redisplay' are
+of the selected window; if INTERACTIVE & `recenter-redisplay' are
 non-nil, also erase the entire frame and redraw it (when
 `auto-resize-tool-bars' is set to `grow-only', this resets the
 tool-bar's height to the minimum height needed); if
 `recenter-redisplay' has the special value `tty', then only tty frames
-are redrawn.  Interactively, REDISPLAY is always non-nil.
+are redrawn.  Interactively, INTERACTIVE is always non-nil.
 
 Just C-u as prefix means put point in the center of the window
 and redisplay normally--don't erase and redraw the frame.  */)
-  (Lisp_Object arg, Lisp_Object redisplay)
+  (Lisp_Object arg, Lisp_Object interactive)
 {
   struct window *w = XWINDOW (selected_window);
   struct buffer *buf = XBUFFER (w->contents);
@@ -5973,7 +5973,7 @@ and redisplay normally--don't erase and redraw the frame.  */)
 
   if (NILP (arg))
     {
-      if (!NILP (redisplay)
+      if (!NILP (interactive)
 	  && !NILP (Vrecenter_redisplay)
 	  && (!EQ (Vrecenter_redisplay, Qtty)
 	      || !NILP (Ftty_type (selected_frame))))

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 32839@debbugs.gnu.org
> Date: Sun, 30 Sep 2018 02:32:57 +0300
> 
> I see that before the recent changes, on a TTY 'C-l' and
> all non-interactive calls of 'recenter' cleared the frame,
> but now only interactive calls of 'recenter' redraw the frame.

More or less, yes.  There's still a way to call 'recenter'
non-interactively in a way that will cause the frame to be redrawn,
but it needs a special arrangement.

> OTOH, what I'm trying to achieve here is to allow C-l with a non-nil
> argument to refresh the *Messages* buffer when recenter-redisplay is t.

That's not C-l's purpose, so IMO you are using the wrong tool for the
job.

> An additional problem is that when 'recenter-positions' is customized
> to not contain the keyword 'middle', then 'recenter-top-bottom' never
> uses a nil arg of 'recenter', thus never redraws the frame.

Again, it is not recenter-redisplay's purpose to redraw the frame.  If
you want to redraw the frame, there's a command for that (and much
more): redraw-display.  There's also a function redraw-frame.

> But since redrawing a frame causes flickering, I'm not interested
> in setting recenter-redisplay to t.  So I could implement more
> fundamental changes for this only if you insist.

I don't think any changes are necessary, because the functions
mentioned all work as intended.  I'm not interested in making the
complex arrangement we already have even more complex.  It is already
quite an unholy mess.

> However, a minimal change that is needed here is to fix inconsistencies
> in the recent changes: the argument name 'redisplay' is confusing -
> it implies that it overrides the default value of recenter-redisplay
> to force the redisplay.  A proper name would be 'interactive'.
> There are dozens of commands already that use this naming convention.

I don't think I agree.  The current name reflects what that argument
causes, you just interpret "redisplay" to mean "redraw the frame",
which is not an accurate interpretation, since the display engine has
its own logic to decide what exactly needs to be redrawn at any
particular moment.

Renaming the argument as you propose would be a step backwards, since
it describes the _purpose_ (as opposed to _effect_) of that argument,
and that could easily change with further development, and is not
accurate even with the current code.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

>> However, a minimal change that is needed here is to fix inconsistencies
>> in the recent changes: the argument name 'redisplay' is confusing -
>> it implies that it overrides the default value of recenter-redisplay
>> to force the redisplay.  A proper name would be 'interactive'.
>> There are dozens of commands already that use this naming convention.
>
> I don't think I agree.  The current name reflects what that argument
> causes, you just interpret "redisplay" to mean "redraw the frame",
> which is not an accurate interpretation, since the display engine has
> its own logic to decide what exactly needs to be redrawn at any
> particular moment.

When an argument name is a verb in the imperative mood, this means only
one thing: it should do what it claims it will do.  If it can't ensure
the result because it interprets it depending on other external conditions,
then the argument should be renamed to e.g. 'maybe-redisplay'.

> Renaming the argument as you propose would be a step backwards, since
> it describes the _purpose_ (as opposed to _effect_) of that argument,
> and that could easily change with further development, and is not
> accurate even with the current code.

Other commands that use the argument name 'interactive' have the same
assumption of describing the purpose, not effect.

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 32839@debbugs.gnu.org
> Date: Sun, 30 Sep 2018 22:40:18 +0300
> 
> > I don't think I agree.  The current name reflects what that argument
> > causes, you just interpret "redisplay" to mean "redraw the frame",
> > which is not an accurate interpretation, since the display engine has
> > its own logic to decide what exactly needs to be redrawn at any
> > particular moment.
> 
> When an argument name is a verb in the imperative mood, this means only
> one thing: it should do what it claims it will do.

And it does: it redisplays the current window.  It does _not_ always
redisplay other windows, and does _not_ redraw the entire frame unless
another argument tells it to do so.

IOW, "redisplay" is not the same as "redraw the frame".  If the
argument's name were "redraw-frame", then I'd agree with you that the
name is misleading.

> > Renaming the argument as you propose would be a step backwards, since
> > it describes the _purpose_ (as opposed to _effect_) of that argument,
> > and that could easily change with further development, and is not
> > accurate even with the current code.
> 
> Other commands that use the argument name 'interactive' have the same
> assumption of describing the purpose, not effect.

It is possible that in other cases that name is the best one we found;
or it could be that some of those arguments need to be renamed to
something else.  The decision is on a per-case basis, and cannot be
global.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

>> The docstring of window-scroll-functions says:
>>
>>   These functions are called whenever the ‘window-start’ marker is modified,
>>   either to point into another buffer (e.g. via ‘set-window-buffer’) or another
>>   place in the same buffer.
>
> You've omitted the first line of the doc string:
>
>   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.

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

>> Maybe it will be called in the new hook window-state-change-functions
>> proposed by Martin.
>
> I hope not.

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.

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.

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, probably at the same time when
post-command-hook is called.

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 32839@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.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

>> 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.

The recipe is essentially the same as for this bug report,
but more complicated.

>> 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.

If window-scroll-functions can't be fixed, then indeed a workaround
is to remember an old value of window-start in pre-command-hook,
and compare it with a new value of window-start in post-command-hook.

bug#32839: 27.0.50; recenter doesn't redisplay

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 32839@debbugs.gnu.org
> Date: Sun, 30 Sep 2018 22:46:47 +0300
> 
> >> 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.
> 
> The recipe is essentially the same as for this bug report,
> but more complicated.

I'd appreciate if you could show the recipe, TIA.

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

>> 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.

I found another case when window-size-change-functions is not called:
it's when invoking winner-undo that restores a previous
window-configuration and where the same window has different
window sizes in prev/next window-configurations.

Perhaps this problem will be fixed by window-state-change-functions that
Martin is currently implementing.

bug#32839: 27.0.50; recenter doesn't redisplay

[martin rudalics]

 > I found another case when window-size-change-functions is not called:
 > it's when invoking winner-undo that restores a previous
 > window-configuration and where the same window has different
 > window sizes in prev/next window-configurations.

Looks like 'set-window-configuration' doesn't trigger a call of
'window-size-change-functions' when it changes only the sizes of
involved windows and no window was added or removed.  I think I can
fix that easily but in the context of Bug#32720 I'm afraid that most
optimizations I tried to apply here are just void anyway.

martin

bug#32839: 27.0.50; recenter doesn't redisplay

[Juri Linkov]

tags 32839 wontfix
close 32839 28.0.50
quit

> Bottom line, I see no problem in the behavior described in this bug
> report, and I think it should be closed.

OK, closed.