all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Winston <wbe@psr.com>
To: Dmitry Gutov <dgutov@yandex.ru>, 28403@debbugs.gnu.org
Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions
Date: Sat,  9 Sep 2017 22:50 EDT	[thread overview]
Message-ID: <201709100250.v8A2o6nL015568@psr.com> (raw)
In-Reply-To: <201709092240.v89MeFUo014854@psr.com>

I previously wrote:
>>     The C code in question uses macros around function arguments in its
>> definitions.  E.g.,
>> 
>>          name _ARGS1(type,variable)
>> 
>>     find-tag (and etags) work just fine with that, and such function
>> definition lines appear in the TAGS file (as they should), but
>> xref-find-definitions fails to find such function tags, saying instead
>> "No definitions found for: name".

Dmitry kindly replied:
> Which program are you generating TAGS with? Is it etags that comes with 
> Emacs?

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

> xref-find-definitions is somewhat stricter about its input than 
> find-tag.

Yes, that's what's causing the difference.  ;-)

> What does the entry for this function inside TAGS look like? [...]
> I'm guessing it looks like:
> 
> name _ARGS1(

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.

Addressing the difference between find-tag and xref-find-definitions:

   find-tag acts as if it uses "^\([^(]+\) *(" [or similar] and
considers the function name to be &1.  I.e., it treats the entire string
"name _ARGS1" as the function name.  When I change the number of
arguments, e.g., "name _ARGS2(...)" and haven't yet updated TAGS,
find-tag reports that it searched for "name _ARGS1" and didn't find it.

   Sure, it would be great if find-tag knew that only the part before
the space is the function name, but *FOR THE PURPOSE OF MAKING
xref-find-definitions WORK AS WELL AS find-tag*, treating [^(]+ (the
entire string up to the '(', or the entire string between the return
value type and the '(' if find-tag is that smart) as the function name
looks like it would do well enough to allow xref-find-definitions to
obsolete find-tag.

>>     So, xref-find-definitions is not yet a complete replacement for
>> find-tag.  Since etags puts such lines in TAGS and xref-find-definitions
>> is unable to match up the name with the tag, it looks like a bug /
>> deficiency in xref-find-definitions.

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

   Thanks,
 -WBE





  parent reply	other threads:[~2017-09-10  2:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-09 22:40 bug#28403: 25.2; find-tag works, but xref-find-definitions doesn't; bug? Winston
2017-09-09 22:58 ` Drew Adams
2017-09-09 23:10 ` Dmitry Gutov
2017-09-10  2:50 ` Winston [this message]
2017-09-10  9:01   ` bug#28403: 25.2; find-tag works, but xref-find-definitions Dmitry Gutov
2017-09-10 14:29   ` Eli Zaretskii
2017-09-10 21:43     ` Dmitry Gutov
2017-09-11  2:38       ` Eli Zaretskii
2017-09-11  8:58         ` Dmitry Gutov
2017-09-11 14:43           ` Eli Zaretskii
2017-09-12 23:40             ` Dmitry Gutov
2017-09-13 15:32               ` Eli Zaretskii
2017-09-14 12:13                 ` Dmitry Gutov
2017-09-14 17:13                   ` Eli Zaretskii
2017-09-19  0:44                     ` Dmitry Gutov
2017-09-19  3:58                       ` Eli Zaretskii
2017-09-10 14:52 ` Winston
2017-09-10 18:27 ` Winston
2017-09-10 19:09   ` Eli Zaretskii
2017-09-10 19:06 ` Winston
2017-09-10 19:10 ` Winston
2017-09-10 20:12 ` Winston
2017-09-11  2:31   ` Eli Zaretskii
2017-09-10 21:19 ` Winston
2017-09-10 21:35   ` Dmitry Gutov
2017-09-11  2:34   ` Eli Zaretskii
2017-09-11  3:19 ` Winston
2017-09-11  4:05 ` Winston
2017-09-11 16:23   ` Eli Zaretskii
2017-09-11  4:11 ` Winston
2017-09-11  5:02 ` Winston
2017-09-11 16:51   ` Eli Zaretskii
2017-09-14 17:37 ` Winston
2017-09-14 22:08   ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201709100250.v8A2o6nL015568@psr.com \
    --to=wbe@psr.com \
    --cc=28403@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.