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

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Fri, 25 Aug 2023 06:50:02 UTC

Severity: wishlist

Found in version 30.0.50

Full log


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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 65520 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>,
 Dmitry Gutov <dmitry <at> gutov.dev>
Subject: Re: bug#65520: 30.0.50; [FR Xref] Project-wide operations
Date: Fri, 25 Aug 2023 09:48:15 +0200
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

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

Note that specifically for Elisp functions, you can use `find-function`
from anywhere (including your C buffers).

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

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

That sounds really interesting!  The way I'd suggest structuring it is
introducing a new command `project-find-definitions` that prompts for an
identifier defined in the current project and jumps to it, similarly to
`xref-find-definitions` but limited to the current project and not
limited to the current `xref` backend.  The way
`project-find-definitions` finds this definitions would be up to the
`project` backend.  Crucially, ISTM that it would be better to build
this as an extension of `project`, not `xref`.  Of course, the "naive
approach" based on `xref` described above would be a perfectly good
starting point for any `project` backend and may be used as a default.


Best,

Eshl




This bug report was last modified 1 year and 289 days ago.

Previous Next


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