bug#68958: [PATCH] Support bookmarking Xref results buffers

[Eshel Yaron]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 11/02/2024 08:18, Eshel Yaron wrote:
>
>> 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.
>
> All right, that's a good point.
>
> Could we really not persist an anonymous function, though? It can be
> printed and, I suppose, evaluated. At least in theory, whatever links
> it has to containing lexical contexts, should be possible to "detach"
> when writing the literal to disk, to be read later.

I'm not sure.  It certainly cant' work for arbitrary function objects
(say, if you create a function with 'make_function' in a module).
>
> The issue with doing this at the level of xref--create-fetcher, is
> that the addition becomes specific to the Xref searches only (find
> definitions/references), and the more generic Xref UI infrastructure
> remains unsupported (such as 'M-x project-find-regexp' or whatever
> calls to xref-show-xrefs exist in third-party packages) -- so those
> Xref buffers would remain not bookmark-able, or they will each require
> specialized code like the one you proposed here.

Yes, but such callers of xref-show-xrefs can implement the same API to
have the corresponding *xref* buffer bookmark-able.  Namely, arrange for
the fetcher function to populate xref-fetcher-alist with relevant data.
Indeed, I plan to work on doing that for project-find-regexp next.  If
we had a solution that doesn't require any work from third party to
benefit from this new feature, that'd be even better, of course.  But
since the current API to Xref frontends accepts any fetcher function,
I'm not sure that's possible...