From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Winston Newsgroups: gmane.emacs.bugs Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Date: Sat, 9 Sep 2017 22:50 EDT Message-ID: <201709100250.v8A2o6nL015568@psr.com> References: <201709092240.v89MeFUo014854@psr.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-Trace: blaine.gmane.org 1505011887 28052 195.159.176.226 (10 Sep 2017 02:51:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Sep 2017 02:51:27 +0000 (UTC) To: Dmitry Gutov , 28403@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 10 04:51:21 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqsKy-0006Rs-3w for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Sep 2017 04:51:08 +0200 Original-Received: from localhost ([::1]:51537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqsL4-0002Vz-36 for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Sep 2017 22:51:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqsKy-0002UZ-02 for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 22:51:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqsKt-0000yD-4C for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 22:51:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49490) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dqsKs-0000y8-W7 for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 22:51:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dqsKs-000749-FB for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 22:51:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <201709092240.v89MeFUo014854@psr.com> Resent-From: Winston Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Sep 2017 02:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28403 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150501180927101 (code B ref 28403); Sun, 10 Sep 2017 02:51:02 +0000 Original-Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 02:50:09 +0000 Original-Received: from localhost ([127.0.0.1]:58171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqsK1-000732-Dt for submit@debbugs.gnu.org; Sat, 09 Sep 2017 22:50:09 -0400 Original-Received: from mail.psr.com ([67.212.42.216]:22435 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqsJz-00072n-Uu for 28403@debbugs.gnu.org; Sat, 09 Sep 2017 22:50:08 -0400 Original-Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8A2o6o8015569 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Sep 2017 22:50:06 -0400 (EDT) (envelope-from wbe@psr.com) Original-Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8A2o6nL015568; Sat, 9 Sep 2017 22:50:06 -0400 (EDT) (envelope-from wbe) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136723 Archived-At: 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