From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>, 68958@debbugs.gnu.org
Subject: bug#68958: [PATCH] Support bookmarking Xref results buffers
Date: Sun, 11 Feb 2024 07:18:56 +0100 [thread overview]
Message-ID: <m1cyt35xrj.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <0b3f4669-180e-466f-96f3-7eeae994581f@gutov.dev> (Dmitry Gutov's message of "Sun, 11 Feb 2024 05:27:27 +0200")
Hi,
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 07/02/2024 14:25, Eli Zaretskii wrote:
>>> To make this happen, we need to propagate some more information to the
>>> "*xref*" buffer (and any other Xref fronted). We do this, without
>>> breaking compatibility, by setting a new variable from inside the xrefs
>>> fetcher function. The frontend can examine this variable to learn all
>>> about the source of the fetched xrefs after invoking the fetcher.
>>> Namely, the "*xref*" buffer uses this information to create bookmarks.
>> Thanks. Frankly, I'm surprised we need such a complex changeset for
>> supporting such a simple extension, but I'll let Dmitry judge that.
>
> A lot of changes seem to stem from the desire to add detailed info
> into the bookmarks's name (including the identifier being searched,
> the search type, and the xref backend in use).
That's not the case. The changes are all meant to facilitate creating
bookmarks that you can restore at a later session. AFAICT the backend,
identifier and search type (kind) are a required for that, no? We use
them to suggest a meaningful bookmark name, but that's just a bonus.
> At the moment our code doesn't save all of those separately, just
> combines them in xref--fetcher.
>
> So whether the patch has to be complex would depend on whether we
> really need to have bookmark names look exactly like proposed. Though
> I'd rewrite it a little even in that case.
Again, the name of the bookmark is really not the focus here. We can't
persist the value of xref--fetcher, since it's an anonymous function, so
we get all the info needed to /recreate/ that function to the frontend.
If there's another (simpler?) way to provide this feature, please do tell.
Best,
Eshel
next prev parent reply other threads:[~2024-02-11 6:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 20:17 bug#68958: [PATCH] Support bookmarking Xref results buffers Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-07 12:25 ` Eli Zaretskii
2024-02-07 17:04 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-11 3:27 ` Dmitry Gutov
2024-02-11 6:18 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-02-11 11:13 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-11 15:34 ` Dmitry Gutov
2024-02-11 17:21 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-11 23:01 ` Dmitry Gutov
2024-02-12 11:45 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-13 3:18 ` Dmitry Gutov
2024-02-13 7:10 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-14 7:14 ` Juri Linkov
2024-02-15 17:57 ` Dmitry Gutov
2024-02-15 21:49 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-15 7:58 ` Juri Linkov
2024-02-15 9:28 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-07 17:25 ` Juri Linkov
2024-02-11 3:21 ` Dmitry Gutov
2024-02-11 17:37 ` Juri Linkov
2024-02-11 22:45 ` Dmitry Gutov
2024-02-12 18:31 ` Juri Linkov
2024-02-12 18:40 ` Dmitry Gutov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1cyt35xrj.fsf@dazzs-mbp.home \
--to=bug-gnu-emacs@gnu.org \
--cc=68958@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=me@eshelyaron.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.