GNU bug report logs - #2544
23.0.60; Could etags please try find a local tag first?

Previous Next

Package: emacs;

Reported by: Matzi Kratzi <matzikratzi <at> gmail.com>

Date: Mon, 2 Mar 2009 21:45:03 UTC

Severity: wishlist

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: larsi <at> gnus.org, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Tue, 20 Jul 2021 14:54:39 +0300
> Cc: matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 20 Jul 2021 02:00:31 +0300
> 
> On 19.07.2021 18:56, Eli Zaretskii wrote:
> > As for the original request: I guess we could satisfy that by having
> > Xref sort the matches so that those in the current buffer come first
> > in the display we show in the*XREF*  buffer?  Dmitry, would it make
> > sense to add such an option, and if so, would it be hard to do so?  In
> > xref--alistify, perhaps, or in xref--analyze?
> 
> It would probably better work as an etags option (residing next to 
> etags-xref-find-definitions-tag-order): Xref, in general, cannot know in 
> advance whether a given tags resides in the current buffer, and 
> following all tags is relatively costly.

But then this feature will be reserved only for the etags backend, no?

Maybe there should be a backend-specific sorting method or something?

> I was thinking to suggest having that behavior on by default (and maybe 
> avoid adding a new variable altogether), but it seems to conflict with 
> the intention behind etags-xref-find-definitions-tag-order, so probably not.

Right.




This bug report was last modified 3 years and 288 days ago.

Previous Next


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