all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.