GNU bug report logs - #65520
30.0.50; [FR Xref] Project-wide operations

Previous Next

Full log

Message #32 received at 65520 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 65520 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
Subject: Re: bug#65520: 30.0.50; [FR Xref] Project-wide operations
Date: Sat, 26 Aug 2023 07:31:05 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 25/08/2023 10:03, Gerd Möllmann wrote:
>> Dmitry Gutov <dmitry <at> 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?

Not yet.  I'm still hoping someone else (tm) builds something, so that I
don't have to do anything.

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

No, I didn't mean Emacs development specifically, although that's
probably the only things I'd use such a facility for.

The whole thing would be like in some IDEs, with their "usual" idea of
project.  I'm not 100% sure, but I think I've seen vscode being used
with different languages (JS, CSS, Java...) and offering such
project-wide stuff.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.