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: Sun, 10 Sep 2017 14:27 EDT Message-ID: <201709101827.v8AIRMse018692@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 1505068107 31125 195.159.176.226 (10 Sep 2017 18:28:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Sep 2017 18:28:27 +0000 (UTC) Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 10 20:28:23 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 1dr6xk-0007Bc-PJ for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Sep 2017 20:28:08 +0200 Original-Received: from localhost ([::1]:53870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dr6xr-0005IX-Sm for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Sep 2017 14:28:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dr6xi-0005H7-Kf for bug-gnu-emacs@gnu.org; Sun, 10 Sep 2017 14:28:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dr6xf-0002mp-Eo for bug-gnu-emacs@gnu.org; Sun, 10 Sep 2017 14:28:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50944) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dr6xf-0002mO-B6 for bug-gnu-emacs@gnu.org; Sun, 10 Sep 2017 14:28:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dr6xf-00064F-4o for bug-gnu-emacs@gnu.org; Sun, 10 Sep 2017 14:28:03 -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 18:28:03 +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.150506804423245 (code B ref 28403); Sun, 10 Sep 2017 18:28:03 +0000 Original-Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 18:27:24 +0000 Original-Received: from localhost ([127.0.0.1]:59620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr6x2-00062r-76 for submit@debbugs.gnu.org; Sun, 10 Sep 2017 14:27:24 -0400 Original-Received: from mail.psr.com ([67.212.42.216]:23140 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr6x1-00062f-Dv for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 14:27:23 -0400 Original-Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8AIRMPw018693 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 14:27:22 -0400 (EDT) (envelope-from wbe@psr.com) Original-Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8AIRMse018692; Sun, 10 Sep 2017 14:27:22 -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:136733 Archived-At: Eli kindly replied: > Could you please post a complete example of the code in question, > including the definition of the _ARGS1 macro, and any other macros and > typedefs that would make the example stand-alone? I think I > understand what has happened, but I'd like to be sure before we decide > what to do about it. Sure (well, it's a semi-complete example). The code, in general, seeks to be as widely compatible with any compiler, ancient or modern, as possible. That's in part because the earliest versions originated back in the 90's when, for example, Sun's bundled cc was a K&R C compiler. The _ARGS* macros provide compatibility between K&R C's name (arg1, arg2) type arg1; type arg2; { ... } and ANSI C's name (type arg1, type arg2) { ... }. _ARGS1 through _ARGS# (enough for whatever function takes the most arguments (or more)) are #define'd in a header file. The other coding style that may matter here is the practice of putting the return value type on a separate line at the function definition (as you'll see below). That makes the function name easier to see (always at the left edge) and allows more arguments to fit on the function name line (nice when grep'ing). The following edited extracts are the basic pieces: ---------- In a common header file: #ifdef __STDC__ # define _ARGS(args) args # define _ARGS0(void) \ (void) # define _ARGS1(A,a) \ (A a) # define _ARGS2(A,a,B,b) \ (A a, B b) # define _ARGS3(A,a,B,b,C,c) \ (A a, B b, C c) [...] #else /* !__STDC__ */ # define _ARGS(args) () # define _ARGS0(args) () # define _ARGS1(A,a) \ (a) \ A a; # define _ARGS2(A,a,B,b) \ (a, b) \ A a; B b; # define _ARGS3(A,a,B,b,C,c) \ (a, b, c) \ A a; B b; C c; [...] #endif /* __STDC__ */ Function declarations use _ARGS(): extern void baz _ARGS((int x, int y)); Function definitions in the *.c files use _ARGS#(): static struct mumblefrotzage * foo _ARGS2(const char *,s, int,n) { ... } int main _ARGS3(int,argc, char**,argv, char**,env) { struct mumblefrotzage *bar = foo ("example", 3); ... } etags would extract "foo _ARGS2(" and "main _ARGS3(" as tag lines. (find-tag) would find foo and main. ---------- Earlier in this thread, Dmitry suggested: >>> 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). to which Eli replied: > Dmitry, how about providing a more user-friendly customization to that > effect? As a "fire escape"? I initially replied to Dmitry's suggestion: >> 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. > I'd rather like to encourage you to continue using xref and report any > issue you find. As you may have seen in my reply to Dmitry, I tried his suggestion, and it seemed to fix the problem in the quick testing I tried, so I'm willing to switch. The main issue I haven't gotten to yet is how best to change the value of etags-xref-find-definitions-tag-order (exfdto) in a way that will maximize long-term compatibility with future Emacs versions. Doing just (setq exfdto '(..)) in ~/.emacs I would expect to be the worst, because either the default value or the symbol names might change in future releases; (setq exfdto (append exfdto '(tag-symbol-match-p))) might be better, but requires preloading etags.el to get the variable's default value. There are also onload hooks, site local lisp, etc. It's not yet clear to me what the best approach is, so I like your suggestion to Dmitry above. :) > [The new xref function] is already better in several areas: I noticed that, and I liked seeing the list of matches when there's >1, rather than having to do {arg} find-tag, possibly repeatedly, when the one find-tag finds first isn't the one I wanted. However, if the basic find wasn't going to work, or was going to have a lot of false positives, then I'd stick with find-tag, which has generally worked well (almost no wrong matches, but it helps that my code tries to have all function names in all files be unique, even when they're static, so there's rarely >1 match). > It is even possible that, given the details I requested above, I will > be able to help you get your use case working with xref, so please > don't give up on xref, not just yet. I haven't. :) Thanks! HTH, -WBE