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


View this message in rfc822 format

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: bug#65520: 30.0.50; [FR Xref] Project-wide operations
Date: Sat, 26 Aug 2023 07:22:11 +0200
Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 25/08/2023 10:03, Gerd Möllmann wrote:
>> 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.
>
> One possible alternative is to treat this situation not like a new
> feature, and write a specialized new Xref backend which would collect
> both the info from Lisp and from TAGS when you are anywhere inside the
> Emacs sources. It shouldn't take too many lines either.
>
> The current existing alternative for that, like Eli pointed out, is
> xref-etags-mode: it disables Elisp's own backend and just uses TAGS
> everywhere ('make tags' in Emacs generates tags for Lisp functions as
> well). With the natural downside that you would need to regen tags
> manually for both types of files now. And that you're using Eglot
> instead ;-(.

Yeah ;-).  That's not what I was looking for. 




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.