bug#2544: 23.0.60; Could etags please try find a local tag first?

[Dmitry Gutov]

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.