GNU bug report logs - #28403
25.2; find-tag works, but xref-find-definitions doesn't; bug?

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Winston <wbe <at> psr.com>, 28403 <at> debbugs.gnu.org
Subject: Re: bug#28403: 25.2; find-tag works, but xref-find-definitions
Date: Sun, 10 Sep 2017 12:01:08 +0300

On 9/10/17 5:49 AM, Winston wrote:

> Yes, and "etags --version" prints: etags (GNU Emacs 25.2)

Thanks.

> Exactly.  E.g.,
> name _ARGS1(^?188,5710
> 
>> which is an "implicit tag name" entry for "_ARGS1", but not for "name".
>> IOW, etags doesn't understand macros.
> 
>     Whether etags understands macros or not, it is correctly identifying
> the lines containing function names, so I see no problem there.

It has a line, but it's a line for tag name "_ARGS1", not "name", by 
etags rules. find-tag just falls back to full text search, which 
xref-find-definitions doesn't, by default.

Because false positives will be more noticeable and annoying in its UI, 
compared to find-tag's.

>> Try adding `tag-symbol-match-p' to
>> etags-xref-find-definitions-tag-order. This example should work then,
>> but you'll get more false positives (like treating return types as
>> function names).
> 
>     Noted for future reference...
> 
>     Since doing that doesn't change what etags writes to TAGS, I'm not
> sure how that elisp change would result in function return types being
> matched as function names, but no matter.

Have you even tried this?

> For the moment I think I'll
> just continue to use find-tag and hope that xref-find-definitions will
> eventually work as well as find-tag before find-tag disappears.  :)

It works better already (more precise results, for inputs that etags 
understands well).

Previous Next

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