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

[Herman]

On 10/1/23 10:51, Eli Zaretskii wrote:
> 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.
Yes, I meant that. If I want to know the line number of a particular 
line, then I use the indicator on the modeline. I wouldn't use 
display-line-numbers with 'visual, because it may not tell this number. 
With your suggestion, it's not possible to tell the line number. With 
magit working with overlays, it is. It's not "just happens to match", 
but designed this way.

To me, it's clear that using overlays for this problem is a better 
solution than using a separate buffer. So far, you didn't say a single 
thing for which using a separate buffer is better. You're just 
suggesting this as workaround for Emacs's limitation. But it's an 
inferior solution. In an ideal world, not every package (which use 
newline-containing overlays) should accomodate to Emacs's limitation, 
but Emacs would be fixed to handle newline-containing overlays better. 
Note: I know that Emacs is free, developed by volunteers, etc., I don't 
want to be sound like someone who tells how to develop Emacs. But in the 
long term, this is the forward-looking solution. I know, someone has to 
do it, it's a large investment.

> 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.
I haven't noticed any problems how magit-blame works in this regard. 
Magit just decorates the buffer. And Emacs should be able to tell for a 
particular line its line number. This should be the easiest part, as 
Emacs doesn't have to do anything special, just tell the line number of 
the point (ignoring all overlays). Why is it fragile?


> > 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.
Do you mean vc-annotate, or something else? Is it possible to edit the 
annotate buffer? And blame information put in a header above the code 
chunk, just like magit's? How can I achieve these?


> > Fair enough. Are these limitations documented?
> Those that are important are indeed documented.
I'm not sure what's documented and what's not. But, I think the fact 
that Emacs has limitations around newline-containing overlays/display 
text-properties is important. So if this is not documented, then it 
should be. Just I alone discovered 3-4 problems with it. Emacs has 
limitations, the manual can have a subsection to list them with a short 
description. If this limitation was documented, this bug and our whole 
discussion may not exist, saving time for both of us. Not just now, but 
I had previous similar bug reports. But now I learned the hard way that 
if Emacs has a bug related to newline-containing overlays, I should not 
report it.