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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2544 in the body.
You can then email your comments to 2544 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Matzi Kratzi <matzikratzi <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; Could etags please try find a local tag first?
Date: Mon, 2 Mar 2009 22:36:40 +0100

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Would it make sense, in general, for etags to first try to find a tag
inside the current buffer? I am working in legacy code that has the
same name for certain help functions in many files. I would like etags
to first try find the tag inside the current buffer.

Please consider the following files:

a.c:
#include <stdio.h>

static void help_func (void)
{
  printf ("ad");
}


void a_func (void)
{
 help_func ();
 printf ("a\n");
}

a.h:
void a_func (void);

b.c:
#include <stdio.h>
#include "a.h"

static void help_func (void);

int main (void)
{
  help_func ();
  a_func ();

 return 0;
}

static void help_func (void)
{
  printf ("kalle\n");
}

c:\src\example>C:\download\emacs-cvs\bin\etags a.c a.h b.c

Then go to the line " help_func ();" in b.c and try find-tag. You will
be taken to the function defined in a.c. I know about "C-u M-.", but
that is not a very big help if there is a big number of files with
different help_funcs.

Best Regards
Mats

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/download/emacs-cvs/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6001)
 of 2009-01-15 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 6.0.6001
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: SVE
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up>
<delete> <delete> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
h e l p _ f u n c <delete> <delete> <delete> <delete>
<delete> <delete> <delete> C-SPC <left> <left> <left>
<left> <left> <left> <left> <left> <left> M-w <down>
<down> <down> <down> <left> <left> <left> <left> <left>
<left> <left> <left> <left> <left> <left> <right> C-y
M-d <down> <down> <down> <down> <down> <down> C-a C-SPC
<down> <down> <down> <down> <down> M-; <up> <up> <up>
<up> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> h e
M-/ M-d C-x C-s <up> <up> <up> <up> <up> <up> <up>
<up> <down> <down> <tab> <down> <tab> <up> <tab> <up>
C-x C-s <up> <up> <up> <end> ; C-x C-s <help-echo>
<down-mouse-1> <mouse-movement> <mouse-movement> <drag-mouse-1>
<help-echo> <down-mouse-2> <mouse-2> M-d <down-mouse-2>
<mouse-2> M-/ M-/ <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> h e
M-/ M-d C-x C-s M-x C-g C-g C-x 5 2 <switch-frame>
M-x s h e l l <return> <help-echo> <down-mouse-1> <mouse-movement>
<mouse-1> c d SPC C-y <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <return>
c d SPC <help-echo> <down-mouse-1> <mouse-movement>
<mouse-movement> <drag-mouse-1> <help-echo> <down-mouse-2>
<mouse-2> <kp-enter> <up> <down> <C-up> <C-up> C-a
<delete> <delete> <delete> <end> e t a g s SPC a .
c SPC <backspace> <backspace> * SPC b * <backspace>
. * <return> C-x C-f T A G S <return> C-x k <return>
<C-up> <left> <left> <left> <left> <left> c SPC a .
h SPC <delete> <delete> <right> <right> <delete> c
<return> C-x C-f <up> <return> C-x k <return> <help-echo>
<switch-frame> <help-echo> <help-echo> <down-mouse-1>
<drag-mouse-1> <down-mouse-1> <mouse-1> <help-echo>
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> M-.
<return> <return> M-* M-x r e p o r t SPC e m a SPC
<tab> <return>

Recent messages:
Quit [2 times]
Mark set
c:/download/emacs-cvs/bin
Mark set
c:/download/src/a
History item: 1
History item: 2
History item: 1
Starting a new list of tags tables
Mark set

Message #12 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Matzi Kratzi <matzikratzi <at> gmail.com>
Cc: 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Mon, 19 Jul 2021 16:48:52 +0200

Matzi Kratzi <matzikratzi <at> gmail.com> writes:

> Would it make sense, in general, for etags to first try to find a tag
> inside the current buffer? I am working in legacy code that has the
> same name for certain help functions in many files. I would like etags
> to first try find the tag inside the current buffer.

(I'm going through old bug reports that unfortunately got no response at
the time.)

I can certainly see cases where that would be useful.  I think much of
this stuff has been rewritten in terms of xref now?  I gave the xref
code a quick look-over, but I didn't see anything obvious in this
area...

Does anybody know whether Emacs grown support for this use case in the
12 years since this bug report was filed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #15 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Mon, 19 Jul 2021 18:56:22 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 19 Jul 2021 16:48:52 +0200
> Cc: 2544 <at> debbugs.gnu.org
> 
> Matzi Kratzi <matzikratzi <at> gmail.com> writes:
> 
> > Would it make sense, in general, for etags to first try to find a tag
> > inside the current buffer? I am working in legacy code that has the
> > same name for certain help functions in many files. I would like etags
> > to first try find the tag inside the current buffer.
> 
> (I'm going through old bug reports that unfortunately got no response at
> the time.)
> 
> I can certainly see cases where that would be useful.  I think much of
> this stuff has been rewritten in terms of xref now?  I gave the xref
> code a quick look-over, but I didn't see anything obvious in this
> area...
> 
> Does anybody know whether Emacs grown support for this use case in the
> 12 years since this bug report was filed?

We did switch to Xref, but for many languages (including C), Xref
still uses etags as its back-end.  So etags is still relevant.

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?

Message #18 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
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.

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.

Message #21 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Tue, 20 Jul 2021 13:51:36 +0200

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

> 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.

Hm...  well, wouldn't sorting the definitions that are in the local file
first fit naturally in that variable?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #24 received at 2544 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.

Message #27 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Tue, 20 Jul 2021 19:15:53 +0300

On 20.07.2021 14:51, Lars Ingebrigtsen wrote:
> Hm...  well, wouldn't sorting the definitions that are in the local file
> first fit naturally in that variable?

Possible, but then we'll need to have two sets of such predicates, as 
well as require more passes over the tags file during the search.

Which isn't free, performance-wise.

Message #30 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Tue, 20 Jul 2021 19:22:41 +0300

On 20.07.2021 14:54, Eli Zaretskii wrote:
>> 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?

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.

Message #33 received at 2544 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Tue, 20 Jul 2021 19:56:53 +0300

> Cc: larsi <at> gnus.org, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 20 Jul 2021 19:22:41 +0300
> 
> > 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.

When a backend returns just one hit, this is a non-issue.  The OP
specifically described a situation where there are many functions with
the same name in the project.  That's the use case we are discussing.
I don't see how the backend can affect this situation.  Especially
since the etags backend is also quite accurate.

But I'm going to stop arguing.  If there isn't enough enthusiasm for
implementing this, it will remain a pipe dream, I guess.

Message #36 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Wed, 21 Jul 2021 01:36:08 +0300

On 20.07.2021 19:56, Eli Zaretskii wrote:

>> 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.
> 
> When a backend returns just one hit, this is a non-issue.  The OP
> specifically described a situation where there are many functions with
> the same name in the project.  That's the use case we are discussing.

Static analysis can very often determine which of the multiple functions 
with the same name will be used at a particular call site. Yes, there 
are exceptions (which will happen less frequently than with etags), like 
when we're trying to jump to a virtual function with overloads in 
several subclasses. But jumping to such function call from a file with 
one of the definitions, and not being able to determine which of the 
functions is going to be called, is going to be an even more rare 
occurrence.

And even so, those backends can choose to sort the results starting with 
the current file by default. No user option needed.

> I don't see how the backend can affect this situation.  Especially
> since the etags backend is also quite accurate.

I'm saying etags' particular characteristics and varied usage patterns 
justify the addition of an etags-specific variable.

I don't see much use for it for other backends, but if I'm proven wrong, 
that proof would also provide some new information which would help 
generalize the feature. This can happen at a later stage.

Message #39 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Wed, 21 Jul 2021 12:39:57 +0200

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

> I'm saying etags' particular characteristics and varied usage patterns
> justify the addition of an etags-specific variable.

The problem is definitely much more noticeable in the etags backend, so
if your judgement is that that's where the option (and sorting) should
go, then please go ahead.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #42 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Tue, 27 Jul 2021 02:15:30 +0300

[Message part 1 (text/plain, inline)]

On 21.07.2021 13:39, Lars Ingebrigtsen wrote:
> The problem is definitely much more noticeable in the etags backend, so
> if your judgement is that that's where the option (and sorting) should
> go, then please go ahead.:-)

Here's a rough patch.

Please test and send feedback (how well it works, variable naming, 
docstring, etc).

[etags-xref-prioritize-same-file.diff (text/x-patch, attachment)]

Message #45 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Wed, 28 Jul 2021 17:49:35 +0200

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

> Here's a rough patch.
>
> Please test and send feedback (how well it works, variable naming,
> docstring, etc).

I've just tested lightly, but it seems to work great for me.  And the
patch looks good to me.  Only extremely minor thing:

> +(defcustom etags-xref-prioritize-same-file nil
> +  "Non-nil to show the matches in the same file first."
> +  :type 'boolean)

:version "28.1"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #48 received at 2544 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Mon, 2 Aug 2021 05:11:54 +0300

On 28.07.2021 18:49, Lars Ingebrigtsen wrote:
>> +(defcustom etags-xref-prioritize-same-file nil
>> +  "Non-nil to show the matches in the same file first."
>> +  :type 'boolean)
> :version "28.1"

Thanks.

Is the above a good variable name? I wasn't sure about it.

Message #51 received at 2544 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Mon, 02 Aug 2021 14:36:21 +0300

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 2 Aug 2021 05:11:54 +0300
> Cc: matzikratzi <at> gmail.com, 2544 <at> debbugs.gnu.org
> 
> On 28.07.2021 18:49, Lars Ingebrigtsen wrote:
> >> +(defcustom etags-xref-prioritize-same-file nil
> >> +  "Non-nil to show the matches in the same file first."
> >> +  :type 'boolean)
> > :version "28.1"
> 
> Thanks.
> 
> Is the above a good variable name? I wasn't sure about it.

I suggest "prefer" instead of "prioritize", and "current" instead of
"same".  ("Same" here leaves me wondering "same as what?")

Message #56 received at 2544-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, matzikratzi <at> gmail.com, 2544-done <at> debbugs.gnu.org
Subject: Re: bug#2544: 23.0.60; Could etags please try find a local tag first?
Date: Fri, 6 Aug 2021 03:17:23 +0300

On 02.08.2021 14:36, Eli Zaretskii wrote:
> I suggest "prefer" instead of "prioritize", and "current" instead of
> "same".  ("Same" here leaves me wondering "same as what?")

Thank you.

With these tweaks, I've installed the patch.

So this bug can (finally?) be closed.

Previous Next

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