GNU bug report logs - #76186
31.0.50; (recenter 0) sometimes does not recenter as expected

Previous Next

To reply to this bug, email your comments to 76186 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; (recenter 0) sometimes does not recenter as expected
Date: Mon, 10 Feb 2025 23:28:35 +0100

To reproduce this issue, please start Emacs with:

    $ emacs -Q

Then paste the forms below in the *scratch* buffer and evaluate them
with M-x eval-buffer RET.

The function `sometimes-not-recentering' (defined below) illustrates the
issue I want to show: Sometimes (recenter 0) works as expected, and
makes (window-start) the same as (point-max). But in some cases, the
recentering does not work as expected. In such a case, the function
throws an exception.

You can invoke the function as often as you want, using for example:

    M-x sometimes-not-recentering RET

and then invoke the function over and over with:

    C-x z z z z z z z z ....

until, at one point, we see in the minibuffer:

    apply: Wrong type argument: stringp, not-recentered

in that case, do C-h e to see additional information in the *Messages*
buffer. For example, after the most recent tries I performed, I got:

    window-start unexpectedly not at point-max (671 != 793) in run 3

This means that the recentering worked twice as expected, and then did
not work as expected in the third run. In some runs I performed with
earlier Emacs versions, recentering worked as expected 200 times and
more in a row, and then did not work as expected after that. After C-x z
z z ..., simply keep "z" pressed until the exception occurs.

The forms follow below. I would greatly appreciate your help with this.
Please let me know any time if you have any questions about this issue.

Thank you and all the best,
Markus


(defvar recentering-test-run 0)

(defun sometimes-not-recentering ()
  (interactive)
  (setq recentering-test-run (1+ recentering-test-run))
  (let ((buf (get-buffer-create "sample")))
    (switch-to-buffer buf)
    (erase-buffer)
    (save-excursion
      (dotimes (i 100)
        (insert (format "line %d\n" i))))
    (let ((frame (make-frame `((parent-frame . ,(selected-frame))
                               (left . 200)
                               (top . 200)
                               (width . (text-pixels . 100))
                               (height . (text-pixels . 100)))))
          (buf (get-buffer-create "buffer-in-frame")))
      (with-selected-frame frame
        (switch-to-buffer buf)
        (erase-buffer)
        (insert "Hello!"))
      (redisplay)
      (delete-frame frame)
      (goto-char (point-max))
      (insert "\n\n")
      (recenter 0)
      (redisplay)
      (unless (= (window-start) (point-max))
        (message "window-start unexpectedly not at point-max (%d != %d) in run %d"
                 (window-start) (point-max) recentering-test-run)
        (setq recentering-test-run 0)
        (error 'not-recentered t)))))



In GNU Emacs 31.0.50 (build 1, x86_64-apple-darwin18.2.0, X toolkit,
 cairo version 1.17.6, Xaw scroll bars) of 2025-01-22 built on
 mac-mini
Repository revision: 34166dcf9cbd961d4f53ce9029e179a21a12c001
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description:  Mac OS X 10.14.2

Configured using:
 'configure --with-x-toolkit=lucid --without-ns
 CFLAGS=-I/opt/local/include/ LDFLAGS=-L/opt/local/lib
 --with-xpm=ifavailable'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBXML2 MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS
TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 LUCID
ZLIB

Message #8 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Tue, 11 Feb 2025 14:39:54 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Date: Mon, 10 Feb 2025 23:28:35 +0100
> 
> 
> To reproduce this issue, please start Emacs with:
> 
>     $ emacs -Q
> 
> Then paste the forms below in the *scratch* buffer and evaluate them
> with M-x eval-buffer RET.
> 
> The function `sometimes-not-recentering' (defined below) illustrates the
> issue I want to show: Sometimes (recenter 0) works as expected, and
> makes (window-start) the same as (point-max). But in some cases, the
> recentering does not work as expected. In such a case, the function
> throws an exception.
> 
> You can invoke the function as often as you want, using for example:
> 
>     M-x sometimes-not-recentering RET
> 
> and then invoke the function over and over with:
> 
>     C-x z z z z z z z z ....
> 
> until, at one point, we see in the minibuffer:
> 
>     apply: Wrong type argument: stringp, not-recentered
> 
> in that case, do C-h e to see additional information in the *Messages*
> buffer. For example, after the most recent tries I performed, I got:
> 
>     window-start unexpectedly not at point-max (671 != 793) in run 3

I cannot reproduce this, at least not after a reasonably long sequence
of z's.

I suspect that this has something to do with dimensions of frame
decorations in your build and the size of the default font on your
system (which is different from mine).

In any case, it is much better to show a recipe that doesn't require
one to endlessly repeat some command until the problem happens (or
doesn't).  In this case, if you can capture the precise dimensions and
position of the frame that cause the problem, just show a simple
one-time recipe with those values.  Then, even if on other platforms
we need to modify the numbers in small ways, it can be done relatively
easily, and the issue then investigated without difficulties.

By contrast, a problem that is hard or impossible to reproduce cannot
be efficiently investigated.

It could also be that the reason is the idiosyncratic implementation
of the various redisplay aspects on macOS, in which case it is
possible that this problem could be reproduce on no other system.

Last, but not least: Emacs never promises that every setting of
window-start will be always obeyed.  The display engine tries to obey
it, but if doing so violates some of the restrictions, like having the
line showing cursor fully visible, it will choose a different
window-start point.  So there's no way to guarantee, in general, that
setting window-start will be obeyed in 100% of cases, with the current
Emacs display engine design.

> In GNU Emacs 31.0.50 (build 1, x86_64-apple-darwin18.2.0, X toolkit,
>  cairo version 1.17.6, Xaw scroll bars) of 2025-01-22 built on
>  mac-mini
> Repository revision: 34166dcf9cbd961d4f53ce9029e179a21a12c001
> Repository branch: master

This is a relatively old build.  Since there were many changes lately
in the display parts, due to new features and fixing regressions, I
suggest to update from Git before you do anything else (unless the
dsame problem exists also on the emacs-30 release branch).

Message #11 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Tue, 11 Feb 2025 21:45:07 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I suspect that this has something to do with dimensions of frame
> decorations in your build and the size of the default font on your
> system (which is different from mine).

Yes indeed, this definitely plays an important role. I have now
constructed a case that exhibits the issue within 10 seconds, with an
Emacs commit from today (0e76716c5faa5e91ac3913b02ba4dc690cf5df83).

It shows the issue also on my Debian system if I invoke Emacs with:

    $ emacs -Q -fn "Deja Vu Sans Mono 15"

and then paste the forms below in the *scratch* buffer, and then do:

    M-x eval-buffer RET

and then wait for about 10 seconds.

The interaction between scroll-bar-mode, frame geometry and other
factors also seems to play a role.

> By contrast, a problem that is hard or impossible to reproduce cannot
> be efficiently investigated.

I will try to simplify the instructions further. For now, I hope you can
use them as they are to at least also see the issue on your system.

> It could also be that the reason is the idiosyncratic implementation
> of the various redisplay aspects on macOS, in which case it is
> possible that this problem could be reproduce on no other system.

Indeed I found the problem much easier to reproduce on OSX, where it
consistently happens within a few tries (also with the latest master
commit from today). However, it also happens on other systems, such as:

    In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw
     scroll bars) of 2025-02-11 built on debian
    Repository revision: 0e76716c5faa5e91ac3913b02ba4dc690cf5df83
    Repository branch: master
    Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
    System Description: Debian GNU/Linux 10 (buster)

    Configured using:
     'configure --with-x-toolkit=lucid --with-xpm=ifavailable
     --with-gif=ifavailable --with-tiff=ifavailable
     --with-gnutls=ifavailable'


> Last, but not least: Emacs never promises that every setting of
> window-start will be always obeyed.  The display engine tries to obey
> it, but if doing so violates some of the restrictions, like having the
> line showing cursor fully visible, it will choose a different
> window-start point.  So there's no way to guarantee, in general, that
> setting window-start will be obeyed in 100% of cases, with the current
> Emacs display engine design.

Yes, thank you for pointing this out. Still, the situation I show here
seems consistently to be the same, and recentering sometimes works as
expected and sometimes not, while the buffer contents and positions are
the same between runs.

The updated Lisp forms follow.

Thank you and all the best,
Markus

;; 1) $ emacs -Q -fn "Deja Vu Sans Mono 15"
;; 2) paste the instructions below to the *scratch* buffer
;; 3) M-x eval-buffer RET
;; 4) wait until an exception is thrown

(menu-bar-mode 0)
(tool-bar-mode 0)
(scroll-bar-mode 0)
(set-frame-height nil 27)
(set-frame-width nil 102)


(defvar recentering-test-run 0)

(defun sometimes-not-recentering ()
  (interactive)
  (setq recentering-test-run (1+ recentering-test-run))
  (let ((buf (get-buffer-create "sample")))
    (switch-to-buffer buf)
    (make-local-variable 'face-remapping-alist)
    (setq face-remapping-alist '((default (:family "DejaVu Sans Mono"
                                                   :height 218))))
    (erase-buffer)
    (save-excursion
      (dotimes (i 100)
        (insert (format "line %d\n" i))))
    (let ((frame (make-frame `((parent-frame . ,(selected-frame))
                               (left . 200)
                               (top . 200)
                               (width . (text-pixels . 100))
                               (height . (text-pixels . 100)))))
          (buf (get-buffer-create "buffer-in-frame")))
      (with-selected-frame frame
        (switch-to-buffer buf)
        (erase-buffer)
        (insert "Hello!"))
      (redisplay)
      (delete-frame frame)
      (kill-buffer buf)
      (goto-char (point-max))
      (insert "\n\n")
      (recenter 0)
      (redisplay)
      (unless (= (window-start) (point-max))
        (message "window-start unexpectedly not at point-max (%d != %d) in run %d"
                 (window-start) (point-max) recentering-test-run)
        (setq recentering-test-run 0)
        (error 'not-recentered t)))))

(while t
  (sometimes-not-recentering))

Message #14 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Wed, 12 Feb 2025 22:09:10 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: 76186 <at> debbugs.gnu.org
> Date: Tue, 11 Feb 2025 21:45:07 +0100
> 
> I will try to simplify the instructions further. For now, I hope you can
> use them as they are to at least also see the issue on your system.

They still don't reproduce the problem for me.  And I cannot really
try playing with the various settings that might affect this because
the recipe runs in a loop, all the time changing the frame being
tested.

Like I said: it will be much easier if you provide just one
configuration for the frame in which you see the problem, because then
I could try changing the font and the dimensions until I succeed in
triggering.

Or maybe you could just post the real-life scenario where this
happened to you.  Or did that also happen when you invoke recenter in
a loop?

> Indeed I found the problem much easier to reproduce on OSX, where it
> consistently happens within a few tries (also with the latest master
> commit from today). However, it also happens on other systems, such as:
> 
>     In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw
>      scroll bars) of 2025-02-11 built on debian
>     Repository revision: 0e76716c5faa5e91ac3913b02ba4dc690cf5df83
>     Repository branch: master
>     Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
>     System Description: Debian GNU/Linux 10 (buster)
> 
>     Configured using:
>      'configure --with-x-toolkit=lucid --with-xpm=ifavailable
>      --with-gif=ifavailable --with-tiff=ifavailable
>      --with-gnutls=ifavailable'

People who can reproduce this are welcome to debug the problem and
describe what they saw.

Message #17 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Wed, 12 Feb 2025 22:09:50 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> They still don't reproduce the problem for me.  And I cannot really
> try playing with the various settings that might affect this because
> the recipe runs in a loop, all the time changing the frame being
> tested.
>
> Like I said: it will be much easier if you provide just one
> configuration for the frame in which you see the problem, because then
> I could try changing the font and the dimensions until I succeed in
> triggering.

The issue the snippet is intended to demonstrate is that recentering
does not work in rare cases, even when used with the exact same settings
as in those cases where it works. This is the reason why a loop is
involved that repeats the exact steps over and over, in order to attempt
to elicit the rare case in which the exact same steps unexpectedly yield
a different result than in all other cases where they are executed.

If I find a test case where recentering always yields an unexpected
result, I will add it immediately to this issue.

> Or maybe you could just post the real-life scenario where this
> happened to you.  Or did that also happen when you invoke recenter in
> a loop?

Yes of course: The real-life scenario where I noticed this problem is a
situation where I use (recenter 0) in an Elisp application, with the
expectation that it - as documented - recenters point at the topmost
line of the window. The application works well, and recentering
generally works as expected. However, I noticed that sometimes (rarely),
it does not work, even in situations where at other times it works as
expected. The snippet I posted is an attempt to distill the essence of
the issue, by retaining only those instructions that suffice to exhibit
the issue on both of the two systems I tested it with so far (OSX and
Debian).

> People who can reproduce this are welcome to debug the problem and
> describe what they saw.

Yes, thank you a lot, it would already help me greatly to know that
someone can also see the issue with the example I posted.  I will also
try to find a way to make it more reproducible, also by testing it on
other systems I have access to.

Thank you and all the best,
Markus

Message #20 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Wed, 12 Feb 2025 22:53:52 +0100

On Wed, 12 Feb 2025 22:09:50 +0100 Markus Triska <triska <at> metalevel.at> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> They still don't reproduce the problem for me.  And I cannot really
>> try playing with the various settings that might affect this because
>> the recipe runs in a loop, all the time changing the frame being
>> tested.
>>
>> Like I said: it will be much easier if you provide just one
>> configuration for the frame in which you see the problem, because then
>> I could try changing the font and the dimensions until I succeed in
>> triggering.
>
> The issue the snippet is intended to demonstrate is that recentering
> does not work in rare cases, even when used with the exact same settings
> as in those cases where it works. This is the reason why a loop is
> involved that repeats the exact steps over and over, in order to attempt
> to elicit the rare case in which the exact same steps unexpectedly yield
> a different result than in all other cases where they are executed.
>
> If I find a test case where recentering always yields an unexpected
> result, I will add it immediately to this issue.
>
>> Or maybe you could just post the real-life scenario where this
>> happened to you.  Or did that also happen when you invoke recenter in
>> a loop?
>
> Yes of course: The real-life scenario where I noticed this problem is a
> situation where I use (recenter 0) in an Elisp application, with the
> expectation that it - as documented - recenters point at the topmost
> line of the window. The application works well, and recentering
> generally works as expected. However, I noticed that sometimes (rarely),
> it does not work, even in situations where at other times it works as
> expected. The snippet I posted is an attempt to distill the essence of
> the issue, by retaining only those instructions that suffice to exhibit
> the issue on both of the two systems I tested it with so far (OSX and
> Debian).
>
>> People who can reproduce this are welcome to debug the problem and
>> describe what they saw.
>
> Yes, thank you a lot, it would already help me greatly to know that
> someone can also see the issue with the example I posted.  I will also
> try to find a way to make it more reproducible, also by testing it on
> other systems I have access to.

I can reproduce the issue, both with the original code snippet and the
current one, on this system:

GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.2) of 2025-02-06 built on strobelfssd
Repository revision: ea04dd8ca93d609c0ee475c4acf58a56dfc0f1f3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Linux From Scratch r12.2-17-systemd

Configured using:
 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig'

I haven't tried to debug it and don't really have a good idea how to
proceed with that, but I'll be happy to try any suggestions.  However, I
will be traveling for about a week and won't be able to do that till the
end of next week at the earliest.

Steve Berman

Message #23 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Wed, 12 Feb 2025 23:05:34 +0100

Stephen Berman <stephen.berman <at> gmx.net> writes:

> I can reproduce the issue, both with the original code snippet and the
> current one, on this system:

Thank you so much Steve! I greatly appreciate you taking the time to try
the example, and I am very glad that you can confirm this issue, because
this may help us to better reproduce and narrow down the problem.

> However, I will be traveling for about a week and won't be able to do
> that till the end of next week at the earliest.

Please enjoy your travel! I am grateful for every input, no matter when
it arrives. I first encountered the issue more than one year ago, and I
look forward to working on it with you when you have time. Please let me
know any time if you have any questions or comments.

Thank you and all the best,
Markus

Message #26 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Thu, 13 Feb 2025 08:23:16 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: 76186 <at> debbugs.gnu.org
> Date: Wed, 12 Feb 2025 22:09:50 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Or maybe you could just post the real-life scenario where this
> > happened to you.  Or did that also happen when you invoke recenter in
> > a loop?
> 
> Yes of course: The real-life scenario where I noticed this problem is a
> situation where I use (recenter 0) in an Elisp application, with the
> expectation that it - as documented - recenters point at the topmost
> line of the window. The application works well, and recentering
> generally works as expected. However, I noticed that sometimes (rarely),
> it does not work, even in situations where at other times it works as
> expected.

What is special or noteworthy about the cases where it doesn't work as
expected?  Is the frame or the window of some special (e.g., small)
dimensions? or is the font used to display characters something
special? or are the lines long? or are lines truncated? or is the
expected window-start point in some special place, or inside a text
property or overlay? anything else that is special about those cases?

Message #29 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Thu, 13 Feb 2025 08:29:25 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76186 <at> debbugs.gnu.org
> Date: Wed, 12 Feb 2025 22:53:52 +0100
> 
> I can reproduce the issue, both with the original code snippet and the
> current one, on this system:
> 
> GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.43, cairo version 1.18.2) of 2025-02-06 built on strobelfssd
> Repository revision: ea04dd8ca93d609c0ee475c4acf58a56dfc0f1f3
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
> System Description: Linux From Scratch r12.2-17-systemd
> 
> Configured using:
>  'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig'
> 
> I haven't tried to debug it and don't really have a good idea how to
> proceed with that, but I'll be happy to try any suggestions.  However, I
> will be traveling for about a week and won't be able to do that till the
> end of next week at the earliest.

Thanks.

If you can investigate the situation where it happens and describe
what goes on there, or maybe even suggest what to do about that, it
will be very appreciated.  Failing that, I hope that you could at
least answer the questions I posted about what is special in the
situation where it does happen.  If you can show a simple recipe that
demonstrates the issue without looping endlessly, it will also help.

Message #32 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Thu, 13 Feb 2025 19:51:35 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> What is special or noteworthy about the cases where it doesn't work as
> expected?

Here is what I found out so far regarding this key question:

Considering a few key indicators, major preconditions of the cases where
it works as expected are exactly identical to the cases where it doesn't
work as expected:

    0. the frame and window geometry are the same and not atypical,
       the font is the same and the characters are only ASCII,
       lines are not overly long and not truncated, no text properties
       or overlays are used in the example I posted
    1. the buffer contents are the same in all cases
    2. point is always at (point-max) when (recenter 0) is invoked
    3. redispay is always called so that recentering can take effect.

Yet, there is something that distinguishes the cases, because in some
cases the recentering works as expected, and in other (rare) cases it
doesn't work as expected even though points (0) to (3) are all the same.
For instance, the loop I posted keeps all these factors the same in each
iteration, yet throws an exception in some but not all iterations.

At one time I believed that undo-auto-current-boundary-timer, which runs
every 10 seconds, may play a role. However, the issue also arises on
both systems I tested even after I cancel the timer.

At another time, I believed that fontification plays a role, but I
eventually found that the issue also arises with font-lock-mode disabled,
and the example I posted does not use font-lock-mode.

I cannot elicit the issue if I remove the creation, modification and
deletion of the frame denoted by `frame' in the snippet I posted. This
could be an indication that the interaction of frames may play a role,
in such a way that some iterations behave differently than others even
though the factors mentioned above are exactly the same in all cases.

Thank you and all the best,
Markus

Message #35 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Thu, 13 Feb 2025 22:48:19 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: 76186 <at> debbugs.gnu.org
> Date: Thu, 13 Feb 2025 19:51:35 +0100
> 
> Considering a few key indicators, major preconditions of the cases where
> it works as expected are exactly identical to the cases where it doesn't
> work as expected:
> 
>     0. the frame and window geometry are the same and not atypical,
>        the font is the same and the characters are only ASCII,
>        lines are not overly long and not truncated, no text properties
>        or overlays are used in the example I posted
>     1. the buffer contents are the same in all cases
>     2. point is always at (point-max) when (recenter 0) is invoked
>     3. redispay is always called so that recentering can take effect.

Is position of point-max relative to the bottom of the window also the
same in the cases where this happens and in those it doesn't?

Message #38 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Thu, 13 Feb 2025 22:35:10 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Is position of point-max relative to the bottom of the window also the
> same in the cases where this happens and in those it doesn't?

In all cases where I can elicit the issue, point-max is at the same
position relative to the bottom of the window, and it is always on line
10 out of 17 fully visible lines in total.

I have uploaded a screenshot that shows the situation when the issue arises:

    https://www.metalevel.at/ei/recenter_sometimes_not_recentering.png

After each iteration of the loop, the expected situation is that the
cursor (which is then at point-max) is in the very first visible line of
the window, and that (window-start) is equal to (point-max), and that is
also what the code I posted tests at the end of each iteration. The
expected situation occurs in most iterations, but not in all iterations.

Sometimes the issue happens after 3000 or more iterations in which
recentering works as expected, and it sometimes also takes longer than
10 seconds of running the loop to elicit the issue.

Message #41 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sat, 22 Feb 2025 14:08:07 +0100

[Message part 1 (text/plain, inline)]

On Thu, 13 Feb 2025 08:29:25 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76186 <at> debbugs.gnu.org
>> Date: Wed, 12 Feb 2025 22:53:52 +0100
>>
>> I can reproduce the issue, both with the original code snippet and the
>> current one, on this system:
>>
>> GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>>  3.24.43, cairo version 1.18.2) of 2025-02-06 built on strobelfssd
>> Repository revision: ea04dd8ca93d609c0ee475c4acf58a56dfc0f1f3
>> Repository branch: master
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
>> System Description: Linux From Scratch r12.2-17-systemd
>>
>> Configured using:
>>  'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig'
>>
>> I haven't tried to debug it and don't really have a good idea how to
>> proceed with that, but I'll be happy to try any suggestions.  However, I
>> will be traveling for about a week and won't be able to do that till the
>> end of next week at the earliest.
>
> Thanks.
>
> If you can investigate the situation where it happens and describe
> what goes on there, or maybe even suggest what to do about that, it
> will be very appreciated.  Failing that, I hope that you could at
> least answer the questions I posted about what is special in the
> situation where it does happen.  If you can show a simple recipe that
> demonstrates the issue without looping endlessly, it will also help.

In the attached file, I've refactored the second code snippet Markus
posted into a single command, which facilitated experimenting with it.
The following is a summary of my observations from experimenting with
the code.  I don't know how useful such impressions are, but that's the
best I could come up with (I tried using Edebug but it alters the
display configuration so I could not get the same test results).

First, I found that I can reproduce the unexpected recentering without
disabling the menu bar, tool bar and scroll bar, and using the default
frame height and width as well as the default font specification.
Moreover, AFAICT the dimensions and placement of the child frame, and
whether the buffer displayed in the child frame has text, are
irrelevant.  (In the attached file the corresponding lines of code are
all commented out.)  However, I cannot reproduce the unexpected
recentering without having a child frame nor without either a loop or
manual iteration -- but sometimes only a single iteration suffices (more
on that below).

When I start Emacs like this:

emacs -Q -l bug#76186.el

and, if the mouse pointer is over the Emacs frame, do not touch the
mouse, then after 501 iterations the loop stops (I've also done tests
with more than 10000 iterations with the same results) and the message
"window-start=793, point-max=793 in run 501" is displayed, indicating
the expected result of `(recenter 0)'.  However, in the displayed
"sample" buffer, point-max is vertically centered in the window (as
after `(recenter)') and window-start is 671.

If I restart Emacs as above and while the loop is running continuously
move the mouse over the frame, I see multiple messages
"window-start=671, point-max=793 in run <N>", indicating the unexpected
recentering, and then a new series of test runs commences.  I
implemented a condition to stop looping when the unexpected recentering
happens on the first iteration (i.e., when N=1), and in all my tests
when moving the mouse over the frame this condition is satisfied at some
point.  The display of the buffer is as above (i.e., as expected when
window-start differs from point-max).  (I tried to programmatically
emulate moving the mouse over the frame with the help of
`set-mouse-position' and `set-mouse-pixel-position', but in both cases
the results were as in the first test without moving the mouse over the
frame.  I noticed that when I manually move the mouse over the frame,
the pointer has the shape of an arrow, while with
set-mouse-{pixel-}position the pointer is an "I-beam".)

If I uncomment the third invocation of `redisplay' in the attached file
and restart Emacs as above and do not move the mouse over the frame, the
result, and the display, on stopping after 501 iterations is as
described above.  However, if I then type `M-x sometimes-not-recentering
RET' and again do not move the mouse over the frame, then on stopping
after 501 iterations the same message "window-start=793, point-max=793
in run 501" is shown but now the buffer display fits the message: point
is at the top left of the window.  Repeating `M-x
sometimes-not-recentering RET' gives the same result and display, though
sometimes there is also a series of test runs (< 501) showing
window-point and point-max differing, but then the next (automatically
started) series ends after 501 iterations with these again identical and
point displayed at top left in the window.  However, this test
configuration appears to be unstable: sometimes on starting Emacs as
above I have gotten the result I get when moving the mouse over the
frame, but this appears to be rare and unpredictable.

If I again comment out the third invocation of `redisplay' and also
comment out the first invocation (thus only the second invocation is
executed), then on starting Emacs as above, in all tests I've made with
this configuration the loop stops immediately after one iteration (one
test series) with the message "window-start=671, point-max=793 in run 1"
and the same display as after the loop stops when moving the mouse over
the frame.  If I then type `M-x sometimes-not-recentering RET', the
result and display are the same, sometimes immediately after one
iteration, sometimes after several series of test runs.

If I leave the first and third invocations of `redisplay' commented out
and also comment out the invocation of `sometimes-not-recentering' at
the bottom of the file, and then start Emacs as above and type `M-x
sometimes-not-recentering RET', then the results and display are
invariably with window-point and point-max differing, but, unlike on all
my tests when the command is executed on loading the file, this
sometimes but not always happens after one test series of one iteration.

Steve Berman

[bug#76186.el (application/emacs-lisp, attachment)]

Message #44 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sat, 22 Feb 2025 15:32:28 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
> Date: Sat, 22 Feb 2025 14:08:07 +0100
> 
> > If you can investigate the situation where it happens and describe
> > what goes on there, or maybe even suggest what to do about that, it
> > will be very appreciated.  Failing that, I hope that you could at
> > least answer the questions I posted about what is special in the
> > situation where it does happen.  If you can show a simple recipe that
> > demonstrates the issue without looping endlessly, it will also help.
> 
> In the attached file, I've refactored the second code snippet Markus
> posted into a single command, which facilitated experimenting with it.
> The following is a summary of my observations from experimenting with
> the code.  I don't know how useful such impressions are, but that's the
> best I could come up with (I tried using Edebug but it alters the
> display configuration so I could not get the same test results).
> 
> First, I found that I can reproduce the unexpected recentering without
> disabling the menu bar, tool bar and scroll bar, and using the default
> frame height and width as well as the default font specification.
> Moreover, AFAICT the dimensions and placement of the child frame, and
> whether the buffer displayed in the child frame has text, are
> irrelevant.  (In the attached file the corresponding lines of code are
> all commented out.)  However, I cannot reproduce the unexpected
> recentering without having a child frame nor without either a loop or
> manual iteration -- but sometimes only a single iteration suffices (more
> on that below).
> 
> When I start Emacs like this:
> 
> emacs -Q -l bug#76186.el
> 
> and, if the mouse pointer is over the Emacs frame, do not touch the
> mouse, then after 501 iterations the loop stops (I've also done tests
> with more than 10000 iterations with the same results) and the message
> "window-start=793, point-max=793 in run 501" is displayed, indicating
> the expected result of `(recenter 0)'.  However, in the displayed
> "sample" buffer, point-max is vertically centered in the window (as
> after `(recenter)') and window-start is 671.
> 
> If I restart Emacs as above and while the loop is running continuously
> move the mouse over the frame, I see multiple messages
> "window-start=671, point-max=793 in run <N>", indicating the unexpected
> recentering, and then a new series of test runs commences.  I
> implemented a condition to stop looping when the unexpected recentering
> happens on the first iteration (i.e., when N=1), and in all my tests
> when moving the mouse over the frame this condition is satisfied at some
> point.  The display of the buffer is as above (i.e., as expected when
> window-start differs from point-max).  (I tried to programmatically
> emulate moving the mouse over the frame with the help of
> `set-mouse-position' and `set-mouse-pixel-position', but in both cases
> the results were as in the first test without moving the mouse over the
> frame.  I noticed that when I manually move the mouse over the frame,
> the pointer has the shape of an arrow, while with
> set-mouse-{pixel-}position the pointer is an "I-beam".)
> 
> If I uncomment the third invocation of `redisplay' in the attached file
> and restart Emacs as above and do not move the mouse over the frame, the
> result, and the display, on stopping after 501 iterations is as
> described above.  However, if I then type `M-x sometimes-not-recentering
> RET' and again do not move the mouse over the frame, then on stopping
> after 501 iterations the same message "window-start=793, point-max=793
> in run 501" is shown but now the buffer display fits the message: point
> is at the top left of the window.  Repeating `M-x
> sometimes-not-recentering RET' gives the same result and display, though
> sometimes there is also a series of test runs (< 501) showing
> window-point and point-max differing, but then the next (automatically
> started) series ends after 501 iterations with these again identical and
> point displayed at top left in the window.  However, this test
> configuration appears to be unstable: sometimes on starting Emacs as
> above I have gotten the result I get when moving the mouse over the
> frame, but this appears to be rare and unpredictable.
> 
> If I again comment out the third invocation of `redisplay' and also
> comment out the first invocation (thus only the second invocation is
> executed), then on starting Emacs as above, in all tests I've made with
> this configuration the loop stops immediately after one iteration (one
> test series) with the message "window-start=671, point-max=793 in run 1"
> and the same display as after the loop stops when moving the mouse over
> the frame.  If I then type `M-x sometimes-not-recentering RET', the
> result and display are the same, sometimes immediately after one
> iteration, sometimes after several series of test runs.
> 
> If I leave the first and third invocations of `redisplay' commented out
> and also comment out the invocation of `sometimes-not-recentering' at
> the bottom of the file, and then start Emacs as above and type `M-x
> sometimes-not-recentering RET', then the results and display are
> invariably with window-point and point-max differing, but, unlike on all
> my tests when the command is executed on loading the file, this
> sometimes but not always happens after one test series of one iteration.

Thanks.  I'm afraid I'm none the wiser, because I see none of the
phenomena you describe on my system.  Whatever I do, the test always
runs to completion, and the last screen shows point at EOB.

Some parts of what you describe seem to indicate that the problem is
not with 'recenter' itself, but with the following redisplay cycle,
which, for some reason, considers the window-start position
inappropriate and recenters point on display.  But I have no idea why,
and it is impossible to debug this when the problem happens as part of
500 iterations.

Message #47 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sat, 22 Feb 2025 14:46:34 +0100

On Sat, 22 Feb 2025 15:32:28 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
>> Date: Sat, 22 Feb 2025 14:08:07 +0100
[...]
>> When I start Emacs like this:
>>
>> emacs -Q -l bug#76186.el
>>
>> and, if the mouse pointer is over the Emacs frame, do not touch the
>> mouse, then after 501 iterations the loop stops (I've also done tests
>> with more than 10000 iterations with the same results) and the message
>> "window-start=793, point-max=793 in run 501" is displayed, indicating
>> the expected result of `(recenter 0)'.  However, in the displayed
>> "sample" buffer, point-max is vertically centered in the window (as
>> after `(recenter)') and window-start is 671.
[...]
> Thanks.  I'm afraid I'm none the wiser, because I see none of the
> phenomena you describe on my system.  Whatever I do, the test always
> runs to completion, and the last screen shows point at EOB.

By "runs to completion" I suppose you mean 501 iterations (or whatever
you set n to)?  In this case is the message as above, with window-start
and point-max identical, or does the message show them differing?  The
latter would be unexpected unless the loop stopped before 501 (or n)
iterations.

> Some parts of what you describe seem to indicate that the problem is
> not with 'recenter' itself, but with the following redisplay cycle,
> which, for some reason, considers the window-start position
> inappropriate and recenters point on display.  But I have no idea why,
> and it is impossible to debug this when the problem happens as part of
> 500 iterations.

I agree, and the apparent ineffectiveness of Edebug in this case is also
frustrating.  I could try using gdb with the test configuration where I
consistly get the "unexpected recentering" after one iteration; can you
suggest where to set the break point and any other input that may be
helpful?

Steve Berman

Message #50 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sat, 22 Feb 2025 16:05:19 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
> Date: Sat, 22 Feb 2025 14:46:34 +0100
> 
> On Sat, 22 Feb 2025 15:32:28 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Thanks.  I'm afraid I'm none the wiser, because I see none of the
> > phenomena you describe on my system.  Whatever I do, the test always
> > runs to completion, and the last screen shows point at EOB.
> 
> By "runs to completion" I suppose you mean 501 iterations (or whatever
> you set n to)?

Yes.

> In this case is the message as above, with window-start
> and point-max identical, or does the message show them differing?

The former.

> The latter would be unexpected unless the loop stopped before 501
> (or n) iterations.

I don't see that.

> > Some parts of what you describe seem to indicate that the problem is
> > not with 'recenter' itself, but with the following redisplay cycle,
> > which, for some reason, considers the window-start position
> > inappropriate and recenters point on display.  But I have no idea why,
> > and it is impossible to debug this when the problem happens as part of
> > 500 iterations.
> 
> I agree, and the apparent ineffectiveness of Edebug in this case is also
> frustrating.  I could try using gdb with the test configuration where I
> consistly get the "unexpected recentering" after one iteration; can you
> suggest where to set the break point and any other input that may be
> helpful?

'recenter' takes effect in two parts: first Emacs determines where to
put window-start, and then redisplay redraws the window according to
that.

The first part is in window.c, in Frecenter, where we have this:

  /* Set the new window start.  */
  set_marker_both (w->start, w->contents, charpos, bytepos);

So first we should determine whether this code determines the
window-start point as expected.  If not, the reason is inside the
implementation of 'recenter'.

The second part is in xdisp.c:redisplay_window, where it attempts to
obey the optional_new_start flag of the window.  It starts here:

  /* If someone specified a new starting point but did not insist,
     check whether it can be used.  */
  if ((w->optional_new_start || window_frozen_p (w))
      && CHARPOS (startp) >= BEGV
      && CHARPOS (startp) <= ZV)
    {
      ptrdiff_t it_charpos;

      w->optional_new_start = false;

This code should set the w->force_start flag.  Does it?  If not, what
prevents that?

Next, we have this:

 force_start:

  /* Handle case where place to start displaying has been specified,
     unless the specified location is outside the accessible range.  */
  if (w->force_start)
    {

The code after this tries to use the specified window-start point, and
the question is: why it eventually rejects it (as what you see seems
to suggest)?

HTH

P.S. It could be that the problem is entirely elsewhere, so don't be
surprised if you step through all of that code and find that Emacs
does indeed succeed to use the window-start point the scenario expects
it to use.

Thanks.

Message #53 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sat, 22 Feb 2025 22:06:18 +0100

On Sat, 22 Feb 2025 16:05:19 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
>> Date: Sat, 22 Feb 2025 14:46:34 +0100
>>
>> On Sat, 22 Feb 2025 15:32:28 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
[...]
>> > Some parts of what you describe seem to indicate that the problem is
>> > not with 'recenter' itself, but with the following redisplay cycle,
>> > which, for some reason, considers the window-start position
>> > inappropriate and recenters point on display.  But I have no idea why,
>> > and it is impossible to debug this when the problem happens as part of
>> > 500 iterations.
>>
>> I agree, and the apparent ineffectiveness of Edebug in this case is also
>> frustrating.  I could try using gdb with the test configuration where I
>> consistly get the "unexpected recentering" after one iteration; can you
>> suggest where to set the break point and any other input that may be
>> helpful?
>
> 'recenter' takes effect in two parts: first Emacs determines where to
> put window-start, and then redisplay redraws the window according to
> that.
>
> The first part is in window.c, in Frecenter, where we have this:
>
>   /* Set the new window start.  */
>   set_marker_both (w->start, w->contents, charpos, bytepos);
>
> So first we should determine whether this code determines the
> window-start point as expected.  If not, the reason is inside the
> implementation of 'recenter'.
>
> The second part is in xdisp.c:redisplay_window, where it attempts to
> obey the optional_new_start flag of the window.  It starts here:
>
>   /* If someone specified a new starting point but did not insist,
>      check whether it can be used.  */
>   if ((w->optional_new_start || window_frozen_p (w))
>       && CHARPOS (startp) >= BEGV
>       && CHARPOS (startp) <= ZV)
>     {
>       ptrdiff_t it_charpos;
>
>       w->optional_new_start = false;
>
> This code should set the w->force_start flag.  Does it?  If not, what
> prevents that?
>
> Next, we have this:
>
>  force_start:
>
>   /* Handle case where place to start displaying has been specified,
>      unless the specified location is outside the accessible range.  */
>   if (w->force_start)
>     {
>
> The code after this tries to use the specified window-start point, and
> the question is: why it eventually rejects it (as what you see seems
> to suggest)?
>
> HTH
>
> P.S. It could be that the problem is entirely elsewhere, so don't be
> surprised if you step through all of that code and find that Emacs
> does indeed succeed to use the window-start point the scenario expects
> it to use.

Thanks for the guidance.  Here is the gdb session transcript produced
for the test configuration where the first and third invocations of
`redisplay' are commented out and only the second invocation is
executed, with the result that, in all tests I've made with this
configuration, the loop stops immediately after one iteration (one test
series) with the message "window-start=671, point-max=793 in run 1" and
the same display as after the loop stops when moving the mouse over the
frame, i.e. a case of "unexpected recentering":

steve [ ~/build/emacs-master/src ]$ gdb ./emacs
GNU gdb (GDB) 15.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = dumb
Breakpoint 1 at 0x14f8d1: file /home/steve/src/emacs/emacs-master/src/emacs.c, line 424.
Breakpoint 2 at 0x113d4e: file /home/steve/src/emacs/emacs-master/src/xterm.c, line 27089.
(gdb) break window.c:7172
Breakpoint 3 at 0xbc850: file /home/steve/src/emacs/emacs-master/src/window.c, line 7172.
(gdb) break xdisp.c:20269
Breakpoint 4 at 0x5555555f90c6: file /home/steve/src/emacs/emacs-master/src/xdisp.c, line 20269.
(gdb) run -Q -l ~/comp/Emacs/bug#76186.el
Starting program: /home/steve/build/emacs-master/src/emacs -Q -l ~/comp/Emacs/bug#76186.el
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffdffd86c0 (LWP 16527)]
[New Thread 0x7fffdf6486c0 (LWP 16528)]
[New Thread 0x7fffdecb86c0 (LWP 16529)]
[New Thread 0x7fffde1706c0 (LWP 16530)]
[New Thread 0x7fffdd7366c0 (LWP 16531)]

Thread 1 "emacs" hit Breakpoint 3, Frecenter (arg=<optimized out>,
    redisplay=<optimized out>)
    at /home/steve/src/emacs/emacs-master/src/window.c:7172
7172	  set_marker_both (w->start, w->contents, charpos, bytepos);
(gdb) n
7178	  w->vscroll = 0;
(gdb) p w->start
$2 = XIL(0x555555d2419d)
(gdb) pr $2
[Thread 0x7fffde1706c0 (LWP 16530) exited]
#<marker at 793 in sample>
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=XIL(0x555555cdd175),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269	  if ((w->optional_new_start || window_frozen_p (w))
(gdb) n
20275	      w->optional_new_start = false;
(gdb) p w->force_start
$3 = false
(gdb) n
20276	      if (!w->force_start)
(gdb)
20278		  start_display (&it, w, startp);
(gdb)
20279		  move_it_to (&it, PT, 0, it.last_visible_y, -1,
(gdb)
20283		  it_charpos = IT_CHARPOS (it);
(gdb)
20289		  if (it.current_y == 0 || line_bottom_y (&it) < it.last_visible_y)
(gdb)
20291		      if (it_charpos == PT)
(gdb)
20292			w->force_start = true;
(gdb) p w->force_start
$4 = false
(gdb) n
20309	  if (!BASE_LINE_NUMBER_VALID_P (w))
(gdb) p w->force_start
$5 = true
(gdb) n
20317	  if (w->force_start)
(gdb)
20322	      w->force_start = false;
(gdb)
20327	      if (!w->preserve_vscroll_p && !window_frozen_p (w))
(gdb)
20328		w->vscroll = 0;
(gdb)
20330	      w->preserve_vscroll_p = false;
(gdb)
20331	      w->window_end_valid = false;
(gdb)
20340	      if (!update_mode_line
(gdb)
20348	      if (CHARPOS (startp) < BEGV)
(gdb)
20350	      else if (CHARPOS (startp) > ZV)
(gdb) p ZV
$6 = 793
(gdb) n
20355	      if (!window_start_acceptable_p (window, CHARPOS (startp)))
(gdb) p CHARPOS (startp)
$7 = <optimized out>
(gdb) n
20363	      clear_glyph_matrix (w->desired_matrix);
(gdb)
20364	      if (!try_window (window, startp, 0))
(gdb)
20371	      if (w->cursor.vpos < 0)
(gdb)
20403	      if (!cursor_row_fully_visible_p (w, false, false, false))
(gdb)
20421	      else if (w->cursor.vpos >= 0)
(gdb)
20426	          int pixel_margin = margin * frame_line_height;
(gdb) p w->cursor.vpos
$8 = 0
(gdb) n
20427		  bool tab_line = window_wants_tab_line (w);
(gdb)
20428		  bool header_line = window_wants_header_line (w);
(gdb)
20434		  if (w->cursor.vpos < margin + tab_line + header_line)
(gdb)
20442		      int window_height = window_box_height (w);
(gdb)
20444		      if (tab_line)
(gdb)
20446		      if (header_line)
(gdb)
20448		      if (w->cursor.y >= window_height - pixel_margin)
(gdb)
20459	      if (new_vpos >= 0)
(gdb)
20502	      if (w->cursor.vpos < 0
(gdb)
21017	  SET_TEXT_POS_FROM_MARKER (startp, w->start);
(gdb) p startp
$9 = <optimized out>
(gdb) p w->start
$10 = XIL(0x555555d2419d)
(gdb) pr $10
#<marker at 793 in sample>
(gdb) n
21018	  w->start_at_line_beg = (CHARPOS (startp) == BEGV
(gdb)
21022	  if ((update_mode_line
(gdb) p w->start_at_line_beg
$11 = true
(gdb) n
21040	      specpdl_ref count1 = SPECPDL_INDEX ();
(gdb)
21042	      specbind (Qinhibit_quit, Qt);
(gdb)
21043	      display_mode_lines (w);
(gdb)
21044	      unbind_to (count1, Qnil);
(gdb)
21048	      if (window_wants_mode_line (w)
(gdb)
21059	      if (window_wants_tab_line (w)
(gdb)
21070	      if (window_wants_header_line (w)
(gdb)
21079	      if (f->fonts_changed)
(gdb)
21083	  if (!line_number_displayed && w->base_line_pos != -1)
(gdb)
21093	  if (update_mode_line
(gdb)
21098	      if (FRAME_WINDOW_P (f))
(gdb)
21101		  redisplay_menu_p = FRAME_EXTERNAL_MENU_BAR (f);
(gdb)
21109	      if (redisplay_menu_p)
(gdb)
21110	        display_menu_bar (w);
(gdb)
21113	      if (FRAME_WINDOW_P (f))
(gdb)
21115		  if (WINDOWP (f->tab_bar_window)
(gdb)
21122		  if (FRAME_EXTERNAL_TOOL_BAR (f))
(gdb)
21123		    update_frame_tool_bar (f);
(gdb)
21138	      gui_consider_frame_title (w->frame);
(gdb)
21146	  if (FRAME_WINDOW_P (f)
(gdb)
21164	  if (WINDOW_BOTTOM_DIVIDER_WIDTH (w))
(gdb)
493	  return XUNTAG (a, Lisp_Vectorlike, struct window);
(gdb)
1623	  return frame_dimension (f->bottom_divider_width);
(gdb)
21176	   if (WINDOW_HAS_VERTICAL_SCROLL_BAR (w) || WINDOW_HAS_HORIZONTAL_SCROLL_BAR (w))
(gdb)
21178	      if (WINDOW_HAS_VERTICAL_SCROLL_BAR (w))
(gdb)
21180		set_vertical_scroll_bar (w);
(gdb)
21182	      if (WINDOW_HAS_HORIZONTAL_SCROLL_BAR (w))
(gdb)
21188	      if (FRAME_TERMINAL (f)->redeem_scroll_bar_hook)
(gdb)
21189	        (*FRAME_TERMINAL (f)->redeem_scroll_bar_hook) (w);
(gdb)
21195	  if (CHARPOS (opoint) < BEGV)
(gdb)
21197	  else if (CHARPOS (opoint) > ZV)
(gdb)
21199	  else if (ochars_modiff == CHARS_MODIFF)
(gdb)
21200	    TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
(gdb)
21211	  set_buffer_internal_1 (old);
(gdb)
21214	  if (CHARPOS (lpoint) <= ZV)
(gdb)
21216	      if (lchars_modiff == CHARS_MODIFF)
(gdb)
21217		TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
(gdb)
21222	  unbind_to (count, Qnil);
(gdb)
redisplay_window_0 (window=window <at> entry=XIL(0x555555cdd175))
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:18126
18126	  return Qnil;
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=XIL(0x555555cdd175),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269	  if ((w->optional_new_start || window_frozen_p (w))
(gdb) n
20309	  if (!BASE_LINE_NUMBER_VALID_P (w))
(gdb) p w->force_start
$12 = false
(gdb) n
20311	    w->base_line_number = 0;
(gdb)
20317	  if (w->force_start)
(gdb)
20520	  if (current_matrix_up_to_date_p
(gdb)
20540	  else if (w->start_at_line_beg
(gdb)
20556	  else if ((tem = try_window_id (w)) != 0)
(gdb)
20570	  else if (CHARPOS (startp) >= BEGV
(gdb)
20677	  if (!update_mode_line)
(gdb)
20684	  if ((0 < scroll_conservatively
(gdb)
20732	  init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
(gdb)
20733	  it.current_y = it.last_visible_y;
(gdb)
20734	  if (centering_position < 0)
(gdb)
20736	      ptrdiff_t margin_pos = CHARPOS (startp);
(gdb)
20742	      if (margin
(gdb)
20760	      scrolling_up = PT > margin_pos;
(gdb)
20761	      aggressive =
(gdb)
20766	      if (!MINI_WINDOW_P (w)
(gdb)
20805		centering_position = window_box_height (w) / 2;
(gdb)
20807	  if (current_buffer->long_line_optimizations_p
(gdb)
20820	    move_it_vertically_backward (&it, centering_position);
(gdb)
20829	  if (it.current_y <= 0)
(gdb)
20836	  it.current_x = it.wrap_prefix_width = it.hpos = 0;
(gdb)
20841	  set_marker_both (w->start, Qnil, IT_CHARPOS (it), IT_BYTEPOS (it));
(gdb)
20844	  startp = run_window_scroll_functions (window, it.current.pos);
(gdb)
20849	  itdata = bidi_shelve_cache ();
(gdb)
20853	  if (!current_matrix_up_to_date_p
(gdb)
20863	    use_desired_matrix = (try_window (window, startp, 0) == 1);
(gdb)
20865	  bidi_unshelve_cache (itdata, false);
(gdb)
20870	  if (f->fonts_changed)
(gdb)
20878	  if (w->cursor.vpos < 0)
(gdb)
20924	  if (w->cursor.vpos < 0)
(gdb)
20977	  if (!cursor_row_fully_visible_p (w, false, false, false))
(gdb)
21017	  SET_TEXT_POS_FROM_MARKER (startp, w->start);
(gdb)
21018	  w->start_at_line_beg = (CHARPOS (startp) == BEGV
(gdb) p w->start
$13 = XIL(0x555555d2419d)
(gdb) pr $13
#<marker at 671 in sample>
(gdb) p ZV
$14 = 793
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=XIL(0x555555cdd175),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269	  if ((w->optional_new_start || window_frozen_p (w))
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=XIL(0x555555cdd175),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269	  if ((w->optional_new_start || window_frozen_p (w))
(gdb) c
Continuing.

Thread 1 "emacs" received signal SIGPIPE, Broken pipe.
0x00007ffff31407ef in __GI___libc_write (fd=13, buf=0x555555d07070, nbytes=568)
    at ../sysdeps/unix/sysv/linux/write.c:26
warning: 26	../sysdeps/unix/sysv/linux/write.c: No such file or directory
(gdb)
Continuing.
[Thread 0x7fffdd7366c0 (LWP 16531) exited]
[Thread 0x7fffdf6486c0 (LWP 16528) exited]
[Thread 0x7fffdffd86c0 (LWP 16527) exited]
[Thread 0x7fffefe110c0 (LWP 16526) exited]
[Thread 0x7fffdecb86c0 (LWP 16529) exited]
[New process 16526]
[Inferior 1 (process 16526) exited normally]
(gdb)


As you can see, after hitting the window.c breakpoint and stepping over
set_marker_both, window-start is at 793, i.e. point-max, which is the
expected position after invoking `(recenter 0)'.  After continuing and
hitting the xdisp.c breakpoint, I stepped through the code and saw
w->force_start get set to true, then stepped further until
redisplay_window_0, then continued and hit the breakpoint again, and now
w->force_start was false.  Then I stepped further until
SET_TEXT_POS_FROM_MARKER (startp, w->start), after which window-start
was now at 671, the value displayed in the message after one iteration,
indicating the unexpected recentering.  I cannot tell what caused
window-start to change from 793 to 671.

Steve Berman

Message #56 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sun, 23 Feb 2025 09:02:35 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
> Date: Sat, 22 Feb 2025 22:06:18 +0100
> 
> As you can see, after hitting the window.c breakpoint and stepping over
> set_marker_both, window-start is at 793, i.e. point-max, which is the
> expected position after invoking `(recenter 0)'.  After continuing and
> hitting the xdisp.c breakpoint, I stepped through the code and saw
> w->force_start get set to true, then stepped further until
> redisplay_window_0, then continued and hit the breakpoint again, and now
> w->force_start was false.  Then I stepped further until
> SET_TEXT_POS_FROM_MARKER (startp, w->start), after which window-start
> was now at 671, the value displayed in the message after one iteration,
> indicating the unexpected recentering.  I cannot tell what caused
> window-start to change from 793 to 671.

Thanks.

There are too many unknowns here that need to become knowns.

First, before the first call to redisplay_window returns, it does
this:

  /* Restore current_buffer and value of point in it.  The window
     update may have changed the buffer, so first make sure `opoint'
     is still valid (Bug#6177).  */
  if (CHARPOS (opoint) < BEGV)
    TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE);
  else if (CHARPOS (opoint) > ZV)
    TEMP_SET_PT_BOTH (Z, Z_BYTE);
  else if (ochars_modiff == CHARS_MODIFF)
    TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
  else
    {
      /* If the buffer was modified while we were redisplaying it, we
         cannot trust the correspondence between character and byte
         positions.  This can happen, for example, if we are
         redisplaying *Messages* and some Lisp, perhaps invoked by
         display_mode_lines, signals an error which caused something
         added/deleted to/from the buffer text.  */
      TEMP_SET_PT_BOTH (CHARPOS (opoint), CHAR_TO_BYTE (CHARPOS (opoint)));
    }
  set_buffer_internal_1 (old);
  /* Avoid an abort in TEMP_SET_PT_BOTH if the buffer has become
     shorter.  This can be caused by log truncation in *Messages*.  */
  if (CHARPOS (lpoint) <= ZV)
    {
      if (lchars_modiff == CHARS_MODIFF)
	TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
      else
	TEMP_SET_PT_BOTH (CHARPOS (lpoint), CHAR_TO_BYTE (CHARPOS (lpoint)));
    }

Your trace indicates that TEMP_SET_PT_BOTH was called twice when
executing this fragment, but you haven't shown the values of point
after each one of them.  It is crucial to understand where point was
after the first call to redisplay_window, because any subsequent
scrolling of the window depends on whether point is fully visible in
the viewport.  So please show the value of point as set by these two
calls to TEMP_SET_PT_BOTH.

Next, at the very beginning of redisplay_window we have this:

  if (!just_this_one_p && needs_no_redisplay (w))
    return;

Thus, the second call to redisplay_window was supposed to return
immediately if these conditions were true.  Since it didn't, and
just_this_one_p is false, we can conclude that needs_no_redisplay
returned false, but which condition inside it caused that?

Next, this:

> 20520	  if (current_matrix_up_to_date_p
> (gdb)
> 20540	  else if (w->start_at_line_beg

indicates that current_matrix_up_to_date_p is false, but why is that?
It is set around line 20160:

  current_matrix_up_to_date_p
    = (w->window_end_valid
       && !current_buffer->clip_changed
       && !current_buffer->prevent_redisplay_optimizations_p
       && !window_outdated (w)
       && !composition_break_at_point
       && !hscrolling_current_line_p (w));

Which one of these causes current_matrix_up_to_date_p to become false?
Or maybe it starts at true, but becomes false below:

  /* When windows_or_buffers_changed is non-zero, we can't rely
     on the window end being valid, so set it to zero there.  */
  if (windows_or_buffers_changed)
    {
      /* If window starts on a continuation line, maybe adjust the
	 window start in case the window's width changed.  */
      if (XMARKER (w->start)->buffer == current_buffer)
	compute_window_start_on_continuation_line (w);

      w->window_end_valid = false;
      /* If so, we also can't rely on current matrix
	 and should not fool try_cursor_movement below.  */
      current_matrix_up_to_date_p = false;
    }

Next,

> (gdb)
> 20556	  else if ((tem = try_window_id (w)) != 0)
> (gdb)

indicates that try_window_id returned zero.  I'd be interested to know
why.

> 20570	  else if (CHARPOS (startp) >= BEGV

This indicates that one of the conditions below

  else if (CHARPOS (startp) >= BEGV
	   && CHARPOS (startp) <= ZV
	   && PT >= CHARPOS (startp)
	   && (CHARPOS (startp) < ZV
	       /* Avoid starting at end of buffer.  */
	       || CHARPOS (startp) == BEGV
	       || !window_outdated (w)))

yields false, but which one?

> 20684	  if ((0 < scroll_conservatively
> (gdb)
> 20732	  init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
> (gdb)
> 20733	  it.current_y = it.last_visible_y;
> (gdb)
> 20734	  if (centering_position < 0)

Here we arrive at a place where redisplay_window decided it must
redraw the window by recentering point in the viewport, and that's
what happens afterwards.  So the above questions should explain why
this happens, instead of the expected result: redisplay_window
deciding that the window's display is already up-to-day and needs no
display changes.

Message #59 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Tue, 25 Feb 2025 16:48:55 +0100

On Sun, 23 Feb 2025 09:02:35 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
>> Date: Sat, 22 Feb 2025 22:06:18 +0100
>>
>> As you can see, after hitting the window.c breakpoint and stepping over
>> set_marker_both, window-start is at 793, i.e. point-max, which is the
>> expected position after invoking `(recenter 0)'.  After continuing and
>> hitting the xdisp.c breakpoint, I stepped through the code and saw
>> w->force_start get set to true, then stepped further until
>> redisplay_window_0, then continued and hit the breakpoint again, and now
>> w->force_start was false.  Then I stepped further until
>> SET_TEXT_POS_FROM_MARKER (startp, w->start), after which window-start
>> was now at 671, the value displayed in the message after one iteration,
>> indicating the unexpected recentering.  I cannot tell what caused
>> window-start to change from 793 to 671.
>
> Thanks.
>
> There are too many unknowns here that need to become knowns.
>
> First, before the first call to redisplay_window returns, it does
> this:
>
>   /* Restore current_buffer and value of point in it.  The window
>      update may have changed the buffer, so first make sure `opoint'
>      is still valid (Bug#6177).  */
>   if (CHARPOS (opoint) < BEGV)
>     TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE);
>   else if (CHARPOS (opoint) > ZV)
>     TEMP_SET_PT_BOTH (Z, Z_BYTE);
>   else if (ochars_modiff == CHARS_MODIFF)
>     TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
>   else
>     {
>       /* If the buffer was modified while we were redisplaying it, we
>          cannot trust the correspondence between character and byte
>          positions.  This can happen, for example, if we are
>          redisplaying *Messages* and some Lisp, perhaps invoked by
>          display_mode_lines, signals an error which caused something
>          added/deleted to/from the buffer text.  */
>       TEMP_SET_PT_BOTH (CHARPOS (opoint), CHAR_TO_BYTE (CHARPOS (opoint)));
>     }
>   set_buffer_internal_1 (old);
>   /* Avoid an abort in TEMP_SET_PT_BOTH if the buffer has become
>      shorter.  This can be caused by log truncation in *Messages*.  */
>   if (CHARPOS (lpoint) <= ZV)
>     {
>       if (lchars_modiff == CHARS_MODIFF)
> 	TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
>       else
> 	TEMP_SET_PT_BOTH (CHARPOS (lpoint), CHAR_TO_BYTE (CHARPOS (lpoint)));
>     }
>
> Your trace indicates that TEMP_SET_PT_BOTH was called twice when
> executing this fragment, but you haven't shown the values of point
> after each one of them.  It is crucial to understand where point was
> after the first call to redisplay_window, because any subsequent
> scrolling of the window depends on whether point is fully visible in
> the viewport.  So please show the value of point as set by these two
> calls to TEMP_SET_PT_BOTH.

Thread 1 "emacs" hit Breakpoint 3, redisplay_window (window=XIL(0x555555c826c5),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:21195
21195	  if (CHARPOS (opoint) < BEGV)
(gdb) p w->start
$1 = XIL(0x555555d2782d)
(gdb) pr $1
#<marker at 793 in smple>
(gdb) p PT
$2 = 793
(gdb) p ZV
$3 = 793
(gdb) n
[Thread 0x7fffde16e6c0 (LWP 28706) exited]
21197	  else if (CHARPOS (opoint) > ZV)
(gdb)
21199	  else if (ochars_modiff == CHARS_MODIFF)
(gdb)
21200	    TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
(gdb)
21211	  set_buffer_internal_1 (old);
(gdb) p PT
$4 = 793
(gdb) n
21214	  if (CHARPOS (lpoint) <= ZV)
(gdb)
21216	      if (lchars_modiff == CHARS_MODIFF)
(gdb)
21217		TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
(gdb)
21222	  unbind_to (count, Qnil);
(gdb) p PT
$5 = 793

> Next, at the very beginning of redisplay_window we have this:
>
>   if (!just_this_one_p && needs_no_redisplay (w))
>     return;
>
> Thus, the second call to redisplay_window was supposed to return
> immediately if these conditions were true.  Since it didn't, and
> just_this_one_p is false, we can conclude that needs_no_redisplay
> returned false, but which condition inside it caused that?

(gdb) break xdisp.c:20081
Breakpoint 4 at 0x5555555f8ae8: file /home/steve/src/emacs/emacs-master/src/xdisp.c, line 20081.
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=XIL(0x555555c828e5),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20081
20081	  if (!just_this_one_p && needs_no_redisplay (w))
(gdb) p !just_this_one_p
$6 = 1
(gdb) p needs_no_redisplay (w)
$7 = false
(gdb) p REDISPLAY_SOME_P ()
$8 = 0
(gdb) p !w->redisplay
$9 = 0
(gdb) p !w->update_mode_line
$10 = 0
(gdb) p !f->face_change
$11 = 1
(gdb) p !f->redisplay
$12 = 0
(gdb) p !buffer->text->redisplay
$13 = 0
(gdb) p window_point (w) == w->last_point
$14 = 0

> Next, this:
>
>> 20520	  if (current_matrix_up_to_date_p
>> (gdb)
>> 20540	  else if (w->start_at_line_beg
>
> indicates that current_matrix_up_to_date_p is false, but why is that?
> It is set around line 20160:
>
>   current_matrix_up_to_date_p
>     = (w->window_end_valid
>        && !current_buffer->clip_changed
>        && !current_buffer->prevent_redisplay_optimizations_p
>        && !window_outdated (w)
>        && !composition_break_at_point
>        && !hscrolling_current_line_p (w));
>
> Which one of these causes current_matrix_up_to_date_p to become false?
> Or maybe it starts at true, but becomes false below:
>
>   /* When windows_or_buffers_changed is non-zero, we can't rely
>      on the window end being valid, so set it to zero there.  */
>   if (windows_or_buffers_changed)
>     {
>       /* If window starts on a continuation line, maybe adjust the
> 	 window start in case the window's width changed.  */
>       if (XMARKER (w->start)->buffer == current_buffer)
> 	compute_window_start_on_continuation_line (w);
>
>       w->window_end_valid = false;
>       /* If so, we also can't rely on current matrix
> 	 and should not fool try_cursor_movement below.  */
>       current_matrix_up_to_date_p = false;
>     }

(gdb) break xdisp.c:20520
Breakpoint 5 at 0x5555555f92ea: file /home/steve/src/emacs/emacs-master/src/xdisp.c, line 20520.
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 3, redisplay_window (window=XIL(0x555555c828e5),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:21195
21195	  if (CHARPOS (opoint) < BEGV)
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=XIL(0x555555c826c5),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20081
20081	  if (!just_this_one_p && needs_no_redisplay (w))
(gdb)
Continuing.

Thread 1 "emacs" hit Breakpoint 5, redisplay_window (window=XIL(0x555555c826c5),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20520
20520	  if (current_matrix_up_to_date_p
(gdb) p current_matrix_up_to_date_p
$15 = <optimized out>
(gdb) p w->window_end_valid
$16 = false
(gdb) p !current_buffer->clip_changed
$17 = 1
(gdb) p !current_buffer->prevent_redisplay_optimizations_p
$18 = 0
(gdb) p !window_outdated (w)
$19 = 0
(gdb) p !composition_break_at_point
$20 = 1
(gdb) p !hscrolling_current_line_p (w)
$21 = 1
(gdb) n
20540	  else if (w->start_at_line_beg
(gdb) p current_matrix_up_to_date_p
$22 = <optimized out>

> Next,
>
>> (gdb)
>> 20556	  else if ((tem = try_window_id (w)) != 0)
>> (gdb)
>
> indicates that try_window_id returned zero.  I'd be interested to know
> why.

(gdb) n
20556	  else if ((tem = try_window_id (w)) != 0)
(gdb) p try_window_id (w)
$23 = 0
(gdb) break xdisp.c:22148
Breakpoint 6 at 0x5555555f709a: file /home/steve/src/emacs/emacs-master/src/xdisp.c, line 22149.
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 6, try_window_id (w=w <at> entry=0x555555c826c0)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:22149
22149	{
(gdb) n
22150	  struct frame *f = XFRAME (w->frame);
(gdb)
22155	  if (is_tty_root_frame_with_visible_child (f))
(gdb)
22158	  struct glyph_matrix *current_matrix = w->current_matrix;
(gdb)
22159	  struct glyph_matrix *desired_matrix = w->desired_matrix;
(gdb)
22166	  ptrdiff_t delta = 0, delta_bytes = 0, stop_pos;
(gdb)
22191	  SET_TEXT_POS_FROM_MARKER (start, w->start);
(gdb)

22195	  if (MINI_WINDOW_P (w))
(gdb) 22199	  if (windows_or_buffers_changed || f->cursor_type_changed)
(gdb)
redisplay_window (window=XIL(0x555555c826c5),
    just_this_one_p=just_this_one_p <at> entry=false)
    at /home/steve/src/emacs/emacs-master/src/xdisp.c:20570
20570	  else if (CHARPOS (startp) >= BEGV

>> 20570	  else if (CHARPOS (startp) >= BEGV
>
> This indicates that one of the conditions below
>
>   else if (CHARPOS (startp) >= BEGV
> 	   && CHARPOS (startp) <= ZV
> 	   && PT >= CHARPOS (startp)
> 	   && (CHARPOS (startp) < ZV
> 	       /* Avoid starting at end of buffer.  */
> 	       || CHARPOS (startp) == BEGV
> 	       || !window_outdated (w)))
>
> yields false, but which one?

(gdb) p CHARPOS (startp) >= BEGV
$24 = 1
(gdb) p CHARPOS (startp) <= ZV
$25 = 1
(gdb) p PT >= CHARPOS (startp)
$26 = 1
(gdb) p CHARPOS (startp) < ZV
$27 = 0
(gdb) p CHARPOS (startp) == BEGV
$28 = 0
(gdb) p !window_outdated (w)
$29 = 0

>> 20684	  if ((0 < scroll_conservatively
>> (gdb)
>> 20732	  init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
>> (gdb)
>> 20733	  it.current_y = it.last_visible_y;
>> (gdb)
>> 20734	  if (centering_position < 0)
>
> Here we arrive at a place where redisplay_window decided it must
> redraw the window by recentering point in the viewport, and that's
> what happens afterwards.  So the above questions should explain why
> this happens, instead of the expected result: redisplay_window
> deciding that the window's display is already up-to-day and needs no
> display changes.

Does the trace answer your questions?  If so, can you connect the dots
for me, because I still don't see why the recentering happens.  If not,
can you tell what's still missing?

Steve Berman

Message #62 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sun, 02 Mar 2025 10:42:15 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
> Date: Tue, 25 Feb 2025 16:48:55 +0100
> 
> >> 20570	  else if (CHARPOS (startp) >= BEGV
> >
> > This indicates that one of the conditions below
> >
> >   else if (CHARPOS (startp) >= BEGV
> > 	   && CHARPOS (startp) <= ZV
> > 	   && PT >= CHARPOS (startp)
> > 	   && (CHARPOS (startp) < ZV
> > 	       /* Avoid starting at end of buffer.  */
> > 	       || CHARPOS (startp) == BEGV
> > 	       || !window_outdated (w)))
> >
> > yields false, but which one?
> 
> (gdb) p CHARPOS (startp) >= BEGV
> $24 = 1
> (gdb) p CHARPOS (startp) <= ZV
> $25 = 1
> (gdb) p PT >= CHARPOS (startp)
> $26 = 1
> (gdb) p CHARPOS (startp) < ZV
> $27 = 0
> (gdb) p CHARPOS (startp) == BEGV
> $28 = 0
> (gdb) p !window_outdated (w)
> $29 = 0

So window_outdated returned non-zero.  That function is just

  bool
  window_outdated (struct window *w)
  {
    struct buffer *b = XBUFFER (w->contents);
    return (w->last_modified < BUF_MODIFF (b)
	    || w->last_overlay_modified < BUF_OVERLAY_MODIFF (b));
  }

which means the window's last_modified flag was not updated by the
previous redisplay cycle for some reason.  That probably happens
because some code called mark_window_display_accurate with last
argument 'false', or maybe because that function was not called at the
end of the previous (1st) redisplay cycle in this scenario (recall
that redisplay_window is called twice in this scenario, and it's the
second call that recenters).  If you can find out which call was that,
maybe it will tell us something useful, but in general, if the
window's display is outdated, the display engine will indeed recenter,
because that means the information in window-start is unreliable.  So
I'm guessing that something in the convoluted reproduction recipe
causes Emacs to decide that the window was not fully redrawn, or that
something happened after the 1st redisplay which made the window
outdated, and that is why it centers point in the window.

> Does the trace answer your questions?  If so, can you connect the dots
> for me, because I still don't see why the recentering happens.

Recentering of point in the window is the default strategy of
redisplaying a window when all else failed or was found inapplicable.
That's what happens here, for some subtle reason whose cause is in the
recipe.  AFAIU, point is still at EOB when this happens, so the only
problem is the expectation that window-start will always be at EOB
after the call (recenter 0), which evidently is not 100% reliable.

Thanks.

Message #65 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephen.berman <at> gmx.net
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sat, 15 Mar 2025 13:07:59 +0200

Ping!  Do we still need to discuss this issue?  Or can it be closed,
given my explanations below?

> Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
> Date: Sun, 02 Mar 2025 10:42:15 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Stephen Berman <stephen.berman <at> gmx.net>
> > Cc: triska <at> metalevel.at,  76186 <at> debbugs.gnu.org
> > Date: Tue, 25 Feb 2025 16:48:55 +0100
> > 
> > >> 20570	  else if (CHARPOS (startp) >= BEGV
> > >
> > > This indicates that one of the conditions below
> > >
> > >   else if (CHARPOS (startp) >= BEGV
> > > 	   && CHARPOS (startp) <= ZV
> > > 	   && PT >= CHARPOS (startp)
> > > 	   && (CHARPOS (startp) < ZV
> > > 	       /* Avoid starting at end of buffer.  */
> > > 	       || CHARPOS (startp) == BEGV
> > > 	       || !window_outdated (w)))
> > >
> > > yields false, but which one?
> > 
> > (gdb) p CHARPOS (startp) >= BEGV
> > $24 = 1
> > (gdb) p CHARPOS (startp) <= ZV
> > $25 = 1
> > (gdb) p PT >= CHARPOS (startp)
> > $26 = 1
> > (gdb) p CHARPOS (startp) < ZV
> > $27 = 0
> > (gdb) p CHARPOS (startp) == BEGV
> > $28 = 0
> > (gdb) p !window_outdated (w)
> > $29 = 0
> 
> So window_outdated returned non-zero.  That function is just
> 
>   bool
>   window_outdated (struct window *w)
>   {
>     struct buffer *b = XBUFFER (w->contents);
>     return (w->last_modified < BUF_MODIFF (b)
> 	    || w->last_overlay_modified < BUF_OVERLAY_MODIFF (b));
>   }
> 
> which means the window's last_modified flag was not updated by the
> previous redisplay cycle for some reason.  That probably happens
> because some code called mark_window_display_accurate with last
> argument 'false', or maybe because that function was not called at the
> end of the previous (1st) redisplay cycle in this scenario (recall
> that redisplay_window is called twice in this scenario, and it's the
> second call that recenters).  If you can find out which call was that,
> maybe it will tell us something useful, but in general, if the
> window's display is outdated, the display engine will indeed recenter,
> because that means the information in window-start is unreliable.  So
> I'm guessing that something in the convoluted reproduction recipe
> causes Emacs to decide that the window was not fully redrawn, or that
> something happened after the 1st redisplay which made the window
> outdated, and that is why it centers point in the window.
> 
> > Does the trace answer your questions?  If so, can you connect the dots
> > for me, because I still don't see why the recentering happens.
> 
> Recentering of point in the window is the default strategy of
> redisplaying a window when all else failed or was found inapplicable.
> That's what happens here, for some subtle reason whose cause is in the
> recipe.  AFAIU, point is still at EOB when this happens, so the only
> problem is the expectation that window-start will always be at EOB
> after the call (recenter 0), which evidently is not 100% reliable.
> 
> Thanks.
> 
> 
> 
> 

Message #68 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sat, 15 Mar 2025 12:28:17 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping!  Do we still need to discuss this issue?  Or can it be closed,
> given my explanations below?

I can still reproduce the problem on 3 different Emacs installations
(Debian, Ubuntu and OSX), and I would prefer this issue only to be
closed when Emacs handles the example reliably because I consider it
unsaticsfactory that recentering sometimes work, and sometimes not.

The other remaining question is why you cannot reproduce the issue with
your configuration whereas Steve and I can do so on ours.

Thank you and all the best,
Markus

Message #71 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sat, 15 Mar 2025 14:36:29 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: stephen.berman <at> gmx.net,  76186 <at> debbugs.gnu.org
> Date: Sat, 15 Mar 2025 12:28:17 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Ping!  Do we still need to discuss this issue?  Or can it be closed,
> > given my explanations below?
> 
> I can still reproduce the problem on 3 different Emacs installations
> (Debian, Ubuntu and OSX), and I would prefer this issue only to be
> closed when Emacs handles the example reliably because I consider it
> unsaticsfactory that recentering sometimes work, and sometimes not.

I thought I explained why this cannot be done as reliably as you
expect it to be.

> The other remaining question is why you cannot reproduce the issue with
> your configuration whereas Steve and I can do so on ours.

I don't know.

Message #74 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sat, 15 Mar 2025 15:24:42 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I thought I explained why this cannot be done as reliably as you
> expect it to be.

On the other hand, it works reliably in your setup, so there are
circumstances in which this does work reliably. Would it help if we find
a way to give you access to a system that exhibits the issue? Maybe via
a virtual machine that can be run in an emulator, or via SSH access?

Thank you and all the best,
Markus

Message #77 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sat, 15 Mar 2025 17:17:30 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: stephen.berman <at> gmx.net,  76186 <at> debbugs.gnu.org
> Date: Sat, 15 Mar 2025 15:24:42 +0100
> 
> On the other hand, it works reliably in your setup

Or I've been just lucky and didn't bump into the situation where the
problem happens.

> Would it help if we find a way to give you access to a system that
> exhibits the issue? Maybe via a virtual machine that can be run in
> an emulator, or via SSH access?

It is impossible for me to debug problems with GUI display remotely.
And the problem is extremely unlikely to happen in a -nw session.  But
if you can reproduce it in "emacs -Q -nw", with a recipe that doesn't
require hundreds of iterations before it happens, do tell.

Message #80 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sun, 16 Mar 2025 09:47:56 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> It is impossible for me to debug problems with GUI display remotely.
> And the problem is extremely unlikely to happen in a -nw session.  But
> if you can reproduce it in "emacs -Q -nw", with a recipe that doesn't
> require hundreds of iterations before it happens, do tell.

So far, I found no way to elicit the problem with "emacs -nw"! I did run
into a different issue with "emacs -nw", Emacs sometimes crashing with:

    ./emacs(+0x4abde)[0x5575ae316bde]
    /lib/x86_64-linux-gnu/libc.so.6(+0x28150)[0x74c813c28150]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x89)[0x74c813c28209]
    ./emacs(+0x4b115)[0x5575ae317115]
    Segmentation fault (core dumped)

Like the original issue, the crash also occurs some of the time, but not
all of the time. Any test case I can produce for it is likely to also
involve many repeated invocations of the exact same calls. Seeing that
such test cases are not esteemed, I do not look further into the crash,
but I will try to find a way to better reproduce the original issue.

One additional offer I can make is to invite you to a video call or to
any place you would like to meet so that we can look at the issue on a
device, please let me know any time if you are interested in this.

Thank you and all the best,
Markus

Message #83 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 76186 <at> debbugs.gnu.org, stephen.berman <at> gmx.net
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sun, 16 Mar 2025 11:00:47 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: stephen.berman <at> gmx.net,  76186 <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 09:47:56 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > It is impossible for me to debug problems with GUI display remotely.
> > And the problem is extremely unlikely to happen in a -nw session.  But
> > if you can reproduce it in "emacs -Q -nw", with a recipe that doesn't
> > require hundreds of iterations before it happens, do tell.
> 
> So far, I found no way to elicit the problem with "emacs -nw"! I did run
> into a different issue with "emacs -nw", Emacs sometimes crashing with:
> 
>     ./emacs(+0x4abde)[0x5575ae316bde]
>     /lib/x86_64-linux-gnu/libc.so.6(+0x28150)[0x74c813c28150]
>     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x89)[0x74c813c28209]
>     ./emacs(+0x4b115)[0x5575ae317115]
>     Segmentation fault (core dumped)

That is worth a separate bug report, preferably with a full backtrace
from GDB.

> One additional offer I can make is to invite you to a video call or to
> any place you would like to meet so that we can look at the issue on a
> device, please let me know any time if you are interested in this.

Thanks, but that's not really practical for me.

Message #86 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, Markus Triska <triska <at> metalevel.at>
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sun, 16 Mar 2025 14:20:33 +0100

[Message part 1 (text/plain, inline)]

On Sat, 15 Mar 2025 14:36:29 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Markus Triska <triska <at> metalevel.at>
>> Cc: stephen.berman <at> gmx.net,  76186 <at> debbugs.gnu.org
>> Date: Sat, 15 Mar 2025 12:28:17 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Ping!  Do we still need to discuss this issue?  Or can it be closed,
>> > given my explanations below?
>>
>> I can still reproduce the problem on 3 different Emacs installations
>> (Debian, Ubuntu and OSX), and I would prefer this issue only to be
>> closed when Emacs handles the example reliably because I consider it
>> unsaticsfactory that recentering sometimes work, and sometimes not.
>
> I thought I explained why this cannot be done as reliably as you
> expect it to be.
>
>> The other remaining question is why you cannot reproduce the issue with
>> your configuration whereas Steve and I can do so on ours.
>
> I don't know.

Although you already said upthread you could not reproduce the issue
with the test code I posted, I'd ask you to try again with the attached
file, i.e. from the shell:

emacs -Q -l bug#76186.el

This file differs from the one I posted upthread only in that the first
occurrence of `(redisplay)' is commented out, so possibly you overlooked
that when you tested previously (my explanation of my testing was a bit
terse).  With that difference I consistently get the unexpected
recentering after a single iteration.  What's more, I've now also
reproduced this with emacs-30 running under MS-Windows 10 in a virtual
machine (I used emacs-30.1-installer.exe downloaded from a GNU mirror).
Perhaps I missed something when debugging this, so if you can also
reproduce it, you might be able to debug it better than I did.

Steve Berman

[bug#76186.el (application/emacs-lisp, attachment)]

Message #89 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Sun, 16 Mar 2025 17:20:51 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Markus Triska <triska <at> metalevel.at>,  76186 <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 14:20:33 +0100
> 
> Although you already said upthread you could not reproduce the issue
> with the test code I posted, I'd ask you to try again with the attached
> file, i.e. from the shell:
> 
> emacs -Q -l bug#76186.el
> 
> This file differs from the one I posted upthread only in that the first
> occurrence of `(redisplay)' is commented out, so possibly you overlooked
> that when you tested previously (my explanation of my testing was a bit
> terse).  With that difference I consistently get the unexpected
> recentering after a single iteration.  What's more, I've now also
> reproduced this with emacs-30 running under MS-Windows 10 in a virtual
> machine (I used emacs-30.1-installer.exe downloaded from a GNU mirror).
> Perhaps I missed something when debugging this, so if you can also
> reproduce it, you might be able to debug it better than I did.

Will do, thanks.

Message #92 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephen.berman <at> gmx.net
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50;
 (recenter 0) sometimes does not recenter as expected
Date: Sun, 16 Mar 2025 17:47:01 +0200

> Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
> Date: Sun, 16 Mar 2025 17:20:51 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Stephen Berman <stephen.berman <at> gmx.net>
> > Cc: Markus Triska <triska <at> metalevel.at>,  76186 <at> debbugs.gnu.org
> > Date: Sun, 16 Mar 2025 14:20:33 +0100
> > 
> > Although you already said upthread you could not reproduce the issue
> > with the test code I posted, I'd ask you to try again with the attached
> > file, i.e. from the shell:
> > 
> > emacs -Q -l bug#76186.el
> > 
> > This file differs from the one I posted upthread only in that the first
> > occurrence of `(redisplay)' is commented out, so possibly you overlooked
> > that when you tested previously (my explanation of my testing was a bit
> > terse).  With that difference I consistently get the unexpected
> > recentering after a single iteration.  What's more, I've now also
> > reproduced this with emacs-30 running under MS-Windows 10 in a virtual
> > machine (I used emacs-30.1-installer.exe downloaded from a GNU mirror).
> > Perhaps I missed something when debugging this, so if you can also
> > reproduce it, you might be able to debug it better than I did.
> 
> Will do, thanks.

Sigh...  I will look into this when I have time, but from what I've
seen until now, this reproducer is unfortunately not very interesting.
The reason is that it only reproduces the problem if I invoke it
exactly as you show:

  emacs -Q -l bug#76186.el

But if I start "emacs -Q" and then manually load-file bug#76186.el
into the running Emacs, the problem doesn't happen here.  Moreover, if
I make the following small modification of your code, by adding these
3 lines:

  (blink-cursor-mode -1)
  (global-eldoc-mode -1)
  (sit-for 0.1)

just before the call to sometimes-not-recentering, and invoke Emacs
exactly as above, the problem also disappears.  So it looks like at
least one of the reasons in the case that reproduces immediately is
that Emacs starts running the function with the initial GUI frame not
yet finalized (it takes time for the GUI system to initialize and show
a window on the desktop), which is a huge turn-off for me, because
basically we are working with an insufficiently finalized display
arrangement (e.g., who knows what are the frame dimensions known to
the display code at that point?), and that is very uninteresting.

Still, I will try to step through the code when I have time, although
it's unlikely to uncover more than I already said in this thread.

Message #95 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Mon, 17 Mar 2025 13:19:33 +0100

On Sun, 16 Mar 2025 17:47:01 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
>> Date: Sun, 16 Mar 2025 17:20:51 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> > From: Stephen Berman <stephen.berman <at> gmx.net>
>> > Cc: Markus Triska <triska <at> metalevel.at>,  76186 <at> debbugs.gnu.org
>> > Date: Sun, 16 Mar 2025 14:20:33 +0100
>> >
>> > Although you already said upthread you could not reproduce the issue
>> > with the test code I posted, I'd ask you to try again with the attached
>> > file, i.e. from the shell:
>> >
>> > emacs -Q -l bug#76186.el
>> >
>> > This file differs from the one I posted upthread only in that the first
>> > occurrence of `(redisplay)' is commented out, so possibly you overlooked
>> > that when you tested previously (my explanation of my testing was a bit
>> > terse).  With that difference I consistently get the unexpected
>> > recentering after a single iteration.  What's more, I've now also
>> > reproduced this with emacs-30 running under MS-Windows 10 in a virtual
>> > machine (I used emacs-30.1-installer.exe downloaded from a GNU mirror).
>> > Perhaps I missed something when debugging this, so if you can also
>> > reproduce it, you might be able to debug it better than I did.
>>
>> Will do, thanks.
>
> Sigh...  I will look into this when I have time, but from what I've
> seen until now, this reproducer is unfortunately not very interesting.
> The reason is that it only reproduces the problem if I invoke it
> exactly as you show:
>
>   emacs -Q -l bug#76186.el
>
> But if I start "emacs -Q" and then manually load-file bug#76186.el
> into the running Emacs, the problem doesn't happen here.  Moreover, if
> I make the following small modification of your code, by adding these
> 3 lines:
>
>   (blink-cursor-mode -1)
>   (global-eldoc-mode -1)
>   (sit-for 0.1)
>
> just before the call to sometimes-not-recentering, and invoke Emacs
> exactly as above, the problem also disappears.  So it looks like at
> least one of the reasons in the case that reproduces immediately is
> that Emacs starts running the function with the initial GUI frame not
> yet finalized (it takes time for the GUI system to initialize and show
> a window on the desktop), which is a huge turn-off for me, because
> basically we are working with an insufficiently finalized display
> arrangement (e.g., who knows what are the frame dimensions known to
> the display code at that point?), and that is very uninteresting.

I can reproduce your obvervations on MS-Windows 10 in the virtual
machine.  But on GNU/Linux even with the blink-cursor-mode,
global-eldoc-mode and sit-for calls added I still get the unexpected
recentering after a single iteration; and when I invoke emacs -Q and
then load bug#76186.el, I still get the unexpected recentering, not
immediately after one iteration but after only a few, mostly two or
three, and then after only a few test runs (often already the second
one), the unexpected recentering also occurs after a single iteration
(this is both with and without adding the above three invocations to the
test file).  Is there a difference between how MS-Windows and GNU/Linux
create the initial GUI frame that could account for these observations?

> Still, I will try to step through the code when I have time, although
> it's unlikely to uncover more than I already said in this thread.

Thanks, I look forward to your findings.

Steve Berman

Message #98 received at 76186 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 76186 <at> debbugs.gnu.org, triska <at> metalevel.at
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
 expected
Date: Mon, 17 Mar 2025 16:42:28 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 76186 <at> debbugs.gnu.org,  triska <at> metalevel.at
> Date: Mon, 17 Mar 2025 13:19:33 +0100
> 
> Is there a difference between how MS-Windows and GNU/Linux create
> the initial GUI frame that could account for these observations?

I don't know if the difference explains what we see, but frame
creation on X and on Windows are worlds apart.  For starters, on
Windows we have a separate thread in Emacs that is dedicated to
sending, receiving, and processing messages to and from the MS-Windows
GUI system, something that on X is done in the context of the main
Emacs thread.

Previous Next

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