bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline

[Eli Zaretskii]

> Date: Sat, 30 Sep 2023 21:15:49 +0200
> Cc: 66216@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> 
> 
> On 9/30/23 19:37, Eli Zaretskii wrote:
> >>
> >> Then line numbers will be incorrect
> > Why not? it depends on how the buffer text is generated, doesn't it?
> This is an example of magit's default blame presentation mode: 
> http://www.mycpu.org/images/magit-blame.jpeg
> 
> The header in front of each code chunk is an overlay. If we wanted to 
> implement this without overlays (just simple text lines with text 
> properties), then the headers will receive a line number, making the 
> original line number incorrect.

I see no line numbers in the screenshot you posted.

If you mean the line number displayed in the mode line, then this is
just one way of showing line numbers, and it just happens to match the
line numbers of the source file when overlay strings are used.  Other
methods of line number might not behave like that: for example, if you
set display-line-numbers to the value 'visual', the "fake" newlines
produced by overlays will be counted as legitimate lines, and the line
counts will be wrong.

My conclusion is that relying on line-number correspondence is
fragile, and for best results the blame display should show the line
numbers produced by Git.

> >> and also the buffer won't be editable.
> > That is easily made possible from Lisp, isn't it?
> How? The optimal solution is to edit the original buffer right away, 
> just like how magit currently works. Maybe it's possible to sync between 
> the scratch and the original buffer somehow. But this solution is 
> awkward, and I'm sure it has a lot of pitfalls.

Well, the built-in VC mode solves all those issues nicely without
using any overlays.  So it isn't as difficult as you seem to think.

> > A Lisp program written for Emacs definitely _should_ consider
> > limitations and restrictions of the Emacs infrastructure it uses, if
> > it wants to present a convenient, efficient, and well-looking
> > interface to the users.
> Fair enough. Are these limitations documented?

Those that are important are indeed documented.

> Multiple-line overlays seem to work well in a lot of cases, several 
> packages use it. It is just there are some cases where they don't work 
> how one may expect. So one might think that such overlays are fully 
> supported, and these cases are just bugs that can be fixed without too 
> much work.

Like I said, a simple solution is for Magit to override the default
definition of scroll-up-line.