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

[Herman]

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. Without the 
long-line-optimization, it does that. In this case, the optimization is 
not an optimization, but makes things worse.

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.


> > 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. I didn't analyze this problem too deeply, because 
I thought that the fact that emacs scrolls in this case is already a bad 
thing. And it's likely the cause of the scrolling is similar to the 
stopping, because both problem go away with long-line-threshold set to nil.


> > So to go to the end of the file I have to run "(goto-char
> > (point-max))" multiple times. Interestingly, "M->" works fine. But
> > if I remove the recenter call at the end of "end-of-buffer", it also
> > has this odd behavior.
> Which isn't surprising, since with the 'recenter' call removed,
> end-of-buffer is just (goto-char (point-max)).
Yes, but it is still weird how can a final recenter call cause a 
difference. The point movement happened earlier, and it is fixed by a 
later recenter call. But yeah, I suppose the scrolling happens later, 
during redisplay, or similar. I just reported this fact because it may 
help identifying the issue.