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

Previous Next

Full log

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

Previous Next

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