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

[Herman]

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.