GNU bug report logs -
#66216
28.2; scroll-up-line doesn't work if there is a before-string overlay with newline
Previous Next
Full log
View this message in rfc822 format
I have scroll-up/down-line mapped to a key. I'd like to see that if I
press and hold these keys, Emacs can scroll continuously. It doesn't
matter too much if at some position, it jumps 2 (or more) visible lines.
Using prefix arguments is not a good solution for this case, because if
I have a buffer with a lot of such overlays (like magit's blame buffer),
it's very inconvenient that emacs stops very frequently, and then I have
to nag it with a prefix argument to "please scroll further". But of
course I can try to write some elisp function to work around this
limitation.
As scroll-down-line jumps over overlays, so it already scrolls 2 visible
lines in the mentioned case, it would make sense that scroll-up-line
behaves the same as well. The current behavior is not consistent. I'd
expect that if scroll-down-line moves window start somewhere, then
scroll-up-line will undo this. But in this case scroll-down-line will
move 2 lines, then scroll-up-line doesn't do anything.
On 9/29/23 13:28, Eli Zaretskii wrote:
>> Date: Tue, 26 Sep 2023 20:30:53 +0200
>> From: Herman <at> debbugs.gnu.org, Géza <geza.herman <at> gmail.com>
>>
>> This bug exists in 28.2, but on a not too old master as well.
>>
>> Repro:
>> - emacs -Q
>> - M-: (overlay-put (make-overlay 72 72) 'before-string "Fake line\n")
>> - this will put a "Fake line" at the 2nd line of the scratch buffer,
>> (between the two default scratch buffer message lines)
>> - M-x scroll-up-line
>> - this will correctly scroll one line up
>> - M-x scroll-up-line
>> - this is the bug, no scroll happens
>>
>> Also, if the overlay is added at the middle of some line (not at the
>> beginning like in my repro steps), then scroll-up-line will "scroll"
>> until the overlay only, making the overlay to visually move the left
>> side. Then further scroll-up-line commands won't have an effect.
> What do you expect to happen in these cases?
>
> The scroll commands work by telling Emacs which buffer position to use
> as the window-start for the next redisplay; then redisplay kicks in
> and redraws the window using that starting position. But for boring
> technical reasons, Emacs is unable to start displaying a buffer from a
> position where we have a before-string overlay, without displaying
> that before-string first. Which is what you see.
>
> We could scroll one more line in these cases, but then the other group
> of users will come up complaining that we scroll over too much text
> (no one said the before-string must have only one newline, it could
> have several ones, in which case we will scroll across all of those
> lines). So we punt and let the user invoke the scrolling commands
> with an appropriate prefix argument; for example, in this case, just
> say "C-u 2 M-x scroll-up-line RET", and Bob's your uncle.
>
> But if this is not good enough, please tell what you'd like to see
> instead, given the above limitation of the current display engine, and
> maybe we will find better solutions for this conundrum.
>
> Thanks.
This bug report was last modified 1 year and 259 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.