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
Message #29 received at 66216 <at> debbugs.gnu.org (full text, mbox):
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 suppose this is what you meant by "populating a scratch buffer with
generated text"
>> 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. Using overlays is a much
more straightforward (from the package's viewpoint, and also from the
user's).
> 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?
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.
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.