From: Herman@debbugs.gnu.org, Géza <geza.herman@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 66216@debbugs.gnu.org
Subject: bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline
Date: Sat, 30 Sep 2023 21:15:49 +0200 [thread overview]
Message-ID: <40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@gmail.com> (raw)
In-Reply-To: <83a5t3a7fu.fsf@gnu.org>
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.
next prev parent reply other threads:[~2023-09-30 19:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 18:30 bug#66216: 28.2; scroll-up-line doesn't work if there is a before-string overlay with newline Herman, Géza
2023-09-29 11:28 ` Eli Zaretskii
2023-09-29 11:53 ` Herman, Géza
2023-09-29 15:28 ` Eli Zaretskii
2023-09-30 17:09 ` Herman, Géza
2023-09-30 17:17 ` Eli Zaretskii
2023-09-30 17:29 ` Herman, Géza
2023-09-30 17:37 ` Eli Zaretskii
2023-09-30 19:15 ` Herman, Géza [this message]
2023-10-01 8:51 ` Eli Zaretskii
2023-10-01 12:10 ` Herman, Géza
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40ca88d3-e25d-e24f-6a54-5a5fc6c6f136@gmail.com \
--to=herman@debbugs.gnu.org \
--cc=66216@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=geza.herman@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).