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
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.
This bug report was last modified 1 year and 260 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.