bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eshel Yaron
Subject: bug#65520: 30.0.50; [FR Xref] Project-wide operations
Date: Fri, 25 Aug 2023 09:48:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Gerd Möllmann <gerd.moellmann@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]