GNU bug report logs - #66764
29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Herman Géza <geza.herman <at> gmail.com>
Cc: 66764 <at> debbugs.gnu.org
Subject: Re: bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))"
 instead of jumping
Date: Fri, 27 Oct 2023 08:46:14 +0300

> Date: Thu, 26 Oct 2023 21:12:55 +0200
> Cc: 66764 <at> debbugs.gnu.org
> From: Herman, Géza <geza.herman <at> gmail.com>
> 
> On 10/26/23 20:25, Eli Zaretskii wrote:
> > I didn't yet try to reproduce this, but just reading the description:
> > why do you consider this behavior a problem, let alone a bug?
> I think that pressing the "go to the end of the buffer" key should go to 
> the end of the buffer without any weird-looking scrolling, and it should 
> do it immediately, not in ~0.5 seconds.

I'm not sure what you mean by "should go to the end of the buffer
without any weird-looking scrolling".  The Lisp program you posted
moves point to the end of the buffer, but how to reflect that best on
display is the decision made by the display engine, and it can
legitimately be by scrolling the window (IIUC what you mean by
"weird-looking scrolling").  As for ~0.5 seconds, I don't think I see
this mentioned in your original report, so I'm guessing there are some
aspects of this behavior that you haven't described in full yet, or
maybe I didn't understand your description.  Maybe when I generate the
file with your program, I will understand it better.

> I've just disabled this optimization, not just because of this. It's 
> also not ideal that if I run beginning-of-visual-line at the end of a 
> long line, the point only moves ~1000 characters to the left, instead of 
> moving to the beginning. I didn't report this problem, because I assume 
> it is known (I suppose it's by design how the optimization works?), so I 
> just give this as a feedback on the long-line-optimization feature here.

Yes, this is by design.

> >> In my real case, a much smaller file produces this problem. Also, Emacs
> >> doesn't go to the end of the file, but stops somewhere in the middle (I
> >> was unable to reproduce this issue with a simple configuration).
> > This can legitimately happen if the last line has tall characters or
> > you use line-spacing or something similar.  Again, why is it a
> > problem, as long as EOB is visible after that?
> 
> The buffer is a simple ASCII file, all characters between 32-127 and 
> newline. There are no tall characters. My line-spacing is nil. The 
> problem is that EOB is not visible. Emacs stops at line 19232, but the 
> file has 48263 lines.

You are saying that Emacs stops and doesn't go further towards EOB
afterwards?

Previous Next

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