bug#65520: 30.0.50; [FR Xref] Project-wide operations

[Dmitry Gutov <dmitry@gutov.dev>]

On 25/08/2023 10:03, Gerd Möllmann wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>>> In C mode, Xref works using Eglot, in ELisp mode it uses something
>>> else
>>> (I have no tags tables).  Both work really well, but I apparently have
>>> to be in an ELisp buffer to use one and in a C buffer to use the other.
>>> Feature request: Is it possible to use more than one backend at the
>>> same
>>> time?  So that I could C-M-. to find an ELisp function while being in a
>>> C file?  I couldn't find something like that mentioned in the docs, so I
>>> guess it's not yet possible.
>>
>> No such capability at the moment, but we indeed have an ELPA package
>> xref-union which implements the "merging" feature that has been
>> requested in the past.
> 
> Thanks also to Visuwesh for pointing me to xref-union.

Have you tried it? By setting up both it and the xref-backend-functions 
manually (in a hook) in every relevant buffer you might get more or less 
the requested behavior. If not, what does feel unsatisfying still?

>> A naive approach, or for the new code to search across different open
>> buffers and look for different available xref-backend-functions
>> elements. And then prompt the user, and then call (?) the said
>> function in one of the buffers it was found in, because in all
>> likelihood it would fail in unrelated ones.
>>
>> Perhaps the solution is to add a new facility to Xref, where different
>> "projects" would be able to register globally in. A feature request
>> indeed.
> 
> I'm not sure about the "different project in the same session" thing.
> 
> My mental model is like so: I'm in a Git repo (Emacs), which is, I think
> also a project in the project.el sense.  This project contains differnt
> sets of files for which information is available using different
> backends (Eglot, Etags, others depending on the kind of project).  What
> U'd like to have is something on the level of such a project, if you
> know what mean.  That is, M-. would take all available info for such a
> project into account.

Indeed, it's also a question of mental model, which we might have 
different. When I was saying "different projects" and "register 
globally", I was thinking of being able to jump to Emacs' sources and 
hack them from anywhere: from any other project I might be working on at 
the moment.

If we're talking about Emacs development only, a "combined" backend 
might make more sense (see the other email).