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

[Dmitry Gutov]

On 11/02/2024 19:21, Eshel Yaron wrote:
> 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).

We could detect some such functions (e.g. when the value is a subr, and 
thus not readable), but we would still support a large varied class of 
functions this way.

Also, we'd probably want to limit the size of the printed representation 
(FETCHER created by project-find-regexp currently closes over the full 
list of files, that's too much to save; it will probably be a good idea 
to rewrite it to fetch the list of files anew).

> > 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.

With that, the simple API "patch FETCHER and DISPLAY-ACTION (probably 
nil)" would turn into something at least twice (or 3x) as complex.

I'm not quite convinced that being able to bookmark Xref buffers is 
worth this cost.

Also note that with such addition the clients would basically pass the 
same information twice: they would both create the fetcher, *and* still 
have to produce the data with which this fetcher is created, and the 
logic to work on it.

This information duplication could be avoided perhaps if we split the 
fetcher into a function symbol and arguments (a new optional argument to 
xref-show-xrefs and xref--show-defs, I suppose). When the caller is able 
to restructure the code to pass a named function as the first arg, the 
result should be print-able. But then they'd have to be careful to keep 
the arguments "simple" too, like not referencing the buffer object 
itself (just its name), etc. That's a fair amount of implicit 
requirements...

> Indeed, I plan to work on doing that for project-find-regexp next.

The approach with xref-backend-restore wouldn't work for it because 
there is no backend to work with.

> 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...

Perhaps our interpreter wizards could chime in regarding the 
roundtrip-ability of anonymous functions.

Whatever is required to make this work, would likely still require less 
collective effort than redoing the Xref APIs.