GNU bug report logs -
#66764
29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
Previous Next
Reported by: Geza Herman <geza.herman <at> gmail.com>
Date: Thu, 26 Oct 2023 17:06:02 UTC
Severity: normal
Found in version 29.1
Done: Gregory Heytings <gregory <at> heytings.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 1 year and 185 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.