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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 30 Sep 2023 19:29:51 +0200
> Cc: 66216@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> On 9/30/23 19:17, Eli Zaretskii wrote:
> >
> > Populating a scratch buffer with generated text, for example.
> Then line numbers will be incorrect

Why not? it depends on how the buffer text is generated, doesn't it?

> and also the buffer won't be editable.

That is easily made possible from Lisp, isn't it?

> And maybe there are other drawbacks of this approach. OK, I 
> admit that editable blame buffers is not a very important feature, but I 
> think that it's a good thing that line numbers are correct.

I see no reason why line numbers should be incorrect.  The line
numbers in blame displays are produced by the VCS, not by Emacs, so
they should be correct no matter what.

> And looking at this from the application developer's viewpoint: just
> because Emacs has limitation around overlays, they shouldn't choose
> a worse solution.

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.

> Especially if one doesn't know about the limitation beforehand, but
> it emerges after 90% of the application is finished.

I don't blame anyone, I'm just saying that this was explained years
ago.  In a nutshell, overlays in Emacs were never supposed to support
massive additions of text with newlines via overlay strings, they were
supposed to support relatively short strings that don't change the
line geometry too much.  Many of the original limitations were lifted
during the years, but that can be only done up to a point.