unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Vladimir Kazanov <vekazanov@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] User-defined fringe tooltips (a request for review)
Date: Sun, 7 Apr 2024 18:07:31 +0100	[thread overview]
Message-ID: <CAAs=0-3XMjCrXHpVHqiwR+rMdSmgeKp18oP0aOYC4Kk-Gc4DCQ@mail.gmail.com> (raw)
In-Reply-To: <86y19pz6j9.fsf@gnu.org>

> So I think the danger of not showing the tooltip due to
> invisible text or text that didn't produce any glyphs is not a real
> one, provided that we lift the restriction of having the
> left/right-fringe-help property on the same positions as the display
> property which produces the fringe bitmap display.  Do you agree?

With the implementation provided in the latest patch it doesn't matter
where bitmap was specified, or if it was specified at all. This means,
for example, that the first left-fringe-help property on the line will
be used as a tooltip on the left fringe row for the same line with or
*without* a bitmap.

> It should be enough to put the left/right-fringe-help property on the
> character immediately following the display property, to get the
> tooltip to display in those cases.

It is possible, yes, if you are fine with this approach. Here's a
review of options considered:

1. Use the iterator it used in the display_line function to extract
tooltips from fringe-related display specs (patch v1). This needs
caching Lisp_Objects in glyph_row structures for future retrieval.
This is good because it looks in all specs everywhere, doesn't matter
if the text is visible or not. Bad because it needs storing additional
non-text values in glyph_row.
2. Iterating over buffer text positions of the row (patch v2). Hard to
take into account all variants of text coming from buffers and
strings. This implementation only finds fringe-help in visible text of
the buffer.
3. Iterating of glyphs of the row (patch v3). All visible text, both
from the buffer and strings, is visited by the implementation.

I'd say that option 1 is best for user code as specs are retrieved uniformly.

Option 3 is the cleanest implementation-wise but we'd have to document
limitations and the suggested solution.

So if you're fine with this approach, I'll clean up the documentation
and provide a final patch based on option 3.

-- 
Regards,

Vladimir Kazanov



  reply	other threads:[~2024-04-07 17:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-19 19:38 [PATCH] User-defined fringe tooltips (a request for review) Vladimir Kazanov
2023-12-20 12:31 ` Eli Zaretskii
2023-12-21 16:51   ` Vladimir Kazanov
2023-12-21 17:37     ` Eli Zaretskii
2023-12-23 13:28       ` Vladimir Kazanov
2023-12-23 13:40         ` Eli Zaretskii
2023-12-24 11:31           ` Vladimir Kazanov
2023-12-24 16:54             ` Eli Zaretskii
2024-03-25 15:55               ` Vladimir Kazanov
2024-03-25 17:11                 ` Eli Zaretskii
2024-03-26 22:16                   ` Vladimir Kazanov
2024-03-27 10:59                     ` Vladimir Kazanov
2024-03-27 11:25                       ` Po Lu
2024-03-27 12:48                         ` Vladimir Kazanov
2024-03-27 11:25                       ` Po Lu
2024-03-31  8:36                       ` Eli Zaretskii
2024-04-07 11:14                         ` Vladimir Kazanov
2024-04-07 12:44                           ` Eli Zaretskii
2024-04-07 17:07                             ` Vladimir Kazanov [this message]
2024-04-07 18:40                               ` Eli Zaretskii
2024-04-08 14:41                                 ` Vladimir Kazanov
2024-04-13  9:14                                   ` Eli Zaretskii
2024-04-13  9:32                                     ` Vladimir Kazanov
2024-04-13 11:21                                       ` Eli Zaretskii
2024-04-13 14:53                                         ` Vladimir Kazanov
2024-04-13 15:47                                           ` Eli Zaretskii
2024-03-27 12:14                     ` Eli Zaretskii
2024-03-27 12:48                       ` Vladimir Kazanov

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='CAAs=0-3XMjCrXHpVHqiwR+rMdSmgeKp18oP0aOYC4Kk-Gc4DCQ@mail.gmail.com' \
    --to=vekazanov@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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).