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: Thu, 15 Feb 2024 22:49:26 +0100 [thread overview]
Message-ID: <m1r0hdtn2x.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <622b208a-6e2a-4f47-b243-40846ec48df1@gutov.dev> (Dmitry Gutov's message of "Thu, 15 Feb 2024 19:57:08 +0200")
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 13/02/2024 09:10, Eshel Yaron wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>
>>> Otherwise, the requirements on the arguments are the same (fetcher --
>>> named function, args -- printability).
>> That might work, although it seems rather difficult to explain such
>> requirements, and it's difficult for callers to ensure or even check
>> whether they're kept (how do you know if your argument is too big
>> without printing it in advance?)
>
> You can usually track that on the level of user input. A good rule of
> thumb would be not to pass a generated list of files. And if some
> user's interactive input string is veeeeeery long, well, whatever disk
> space is wasted as a result is their own doing.
I agree, that's a good heuristic.
> What's the alternative, though? Writing a separate bookmark storage
> function for every sort of search? For project, lsp-mode/eglot (they
> both have additional commands doing extra searches), etc?
I think we should have an extensible interface that covers the Xref
commands by default, and allows other callers of `xref-show-xrefs` to
override the default to suite their needs.
> And the return value of xref-backend-context (from your proposal) must
> likewise be print-able and compact enough, right?
Yes, you're right. By default, in my proposal, the return value of this
method is itself a bookmark record (pointing to the position where you
initiate the search), so we rely on the major mode of the original
buffer to define a reasonable `bookmark-make-record-function`. If a
backend overrides the default method, it also needs to take into account
these limitations, indeed.
>> Furthermore, IIUC, what you get is an opaque function and argument list,
>> and the frontend cannot reason about these, it can only apply the
>> function to these arguments to get a list of xrefs. In contrast,
>> xref-fetcher-alist provides clear (documented) semantics.
>
> Which will only work for Xref's own commands but not for any external
> callers of xref-show-xrefs. Right?
It doesn't work out of the box for external callers, but it isn't
strictly restricted to Xref commands either: it works for any caller of
`xref-show-xrefs` that defines a (possibly trivial) Xref backend, and
passes a fetcher function that sets `xref-fetcher-alist`.
`xref-make-fetcher` is supposed to make it easier to create the such a
fetcher function.
>> We use it for
>> bookmarking first and foremost, but the frontend can legitimately use it
>> for other stuff too, like showing some info in the mode line.
>>
>>> Also, I'm not sure how we're supposed to guarantee that
>>> xref--original-buffer is live.
>> In my patch, we don't guarantee that (see
>> xref-bookmark-make-record).
>> And that's fine, it's a best effort to give the backend all the context
>> it might need. If there's no original buffer, we just don't save and
>> restore that bit of context.
>
> Okay, I see that. Basically, you bookmark the "original point" and
> then restore it from xref-backend-restore. So this would work, most of
> the time.
>
>> The backend can handle a nil CONTEXT
>> argument in xref-backend-restore however it sees fit. By default, it
>> does nothing.
>
> I don't any LSP backend could handle nil, though. It would need
> additional data, like the origin file name, the value of point, etc.
Right. For Eglot, we cannot restore a bookmark with nil context, and we
also need to make sure we're connected to the server. Adding something
like the following in eglot.el seems to do the trick:
--8<---------------cut here---------------start------------->8---
(cl-defmethod xref-backend-restore ((_backend (eql eglot)) context)
(unless context
(error "No context available for restoring Xref search"))
(bookmark-handle-bookmark context)
(unless eglot--managed-mode
(apply #'eglot--connect (eglot--guess-contact))))
--8<---------------cut here---------------end--------------->8---
next prev parent reply other threads:[~2024-02-15 21:49 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
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 [this message]
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=m1r0hdtn2x.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.