|
From: | Dmitry Gutov |
Subject: | bug#2544: 23.0.60; Could etags please try find a local tag first? |
Date: | Tue, 20 Jul 2021 19:22:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 20.07.2021 14:54, Eli Zaretskii wrote:
Cc: matzikratzi@gmail.com, 2544@debbugs.gnu.org From: Dmitry Gutov <dgutov@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?
Not 100% sure how that could work, but I'm reasonably certain that "prioritize hits in the current file" is mostly relevant to etags.
Because when one uses more precise backends, "find definition" gets fewer hits, and you don't really need to choose which ones to start with -- the current file or otherwise.
Even if there are exceptions, I think only etags has the problem mentioned below. Other backends could simply always prioritize the current file, no user option needed.
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.
^^^ the aforementioned problem.
[Prev in Thread] | Current Thread | [Next in Thread] |