From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions doesn't; bug? Resent-From: Winston Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Sep 2017 22:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 28403 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 28403@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.15049968305264 (code B ref -1); Sat, 09 Sep 2017 22:41:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Sep 2017 22:40:30 +0000 Received: from localhost ([127.0.0.1]:58019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqoQP-0001Mq-Sk for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:30 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqoQO-0001Md-GT for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqoQI-0007ci-Hj for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:23 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34056) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dqoQI-0007ce-EU for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqoQH-00018H-38 for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 18:40:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqoQD-0007YW-5L for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 18:40:21 -0400 Received: from mail.psr.com ([67.212.42.216]:22149 helo=psr.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dqoQC-0007Vm-W1 for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 18:40:17 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v89MeF4r014855 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Sep 2017 18:40:15 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v89MeFUo014854; Sat, 9 Sep 2017 18:40:15 -0400 (EDT) (envelope-from wbe) Message-Id: <201709092240.v89MeFUo014854@psr.com> Date: Sat, 9 Sep 2017 18:40 EDT From: Winston MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) [Emacs 25.2; it looks (to me) like a regexp match pattern issue in xref.el, not an O/S issue.] Today I noticed the message about find-tag being (supposedly) obsoleted by xref-find-definitions as of Emacs version 25.1, so I tried the new command. Unfortunately, the new one failed completely on an entire class of function definitions. After some experimenting, it appears that the problem may be that xref-find-definitions only works when the function definition is of the form: name spacing* '('. 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". Changing the function definition line to name (type variable) as a test, re-running etags, and reloading TAGS, xref-find-definitions found the tag and went to it. 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. -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions doesn't; bug? Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Sep 2017 22:59:01 +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: To: Winston , 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15049979296827 (code B ref 28403); Sat, 09 Sep 2017 22:59:01 +0000 Received: (at 28403) by debbugs.gnu.org; 9 Sep 2017 22:58:49 +0000 Received: from localhost ([127.0.0.1]:58042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqoi8-0001m3-Ng for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:58:48 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:38992) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqoi6-0001lp-Ql for 28403@debbugs.gnu.org; Sat, 09 Sep 2017 18:58:47 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v89Mwdfw004362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 9 Sep 2017 22:58:40 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v89MwdOW009209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 9 Sep 2017 22:58:39 GMT Received: from ubhmp0015.oracle.com (ubhmp0015.oracle.com [156.151.24.68]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v89MwcKC032134; Sat, 9 Sep 2017 22:58:38 GMT MIME-Version: 1.0 Message-ID: <9d5d87cc-d7b4-4cf6-a548-8fe08f0d9cfb@default> Date: Sat, 9 Sep 2017 22:58:37 +0000 (UTC) From: Drew Adams References: <201709092240.v89MeFUo014854@psr.com> In-Reply-To: <201709092240.v89MeFUo014854@psr.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6774.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -5.1 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > Today I noticed the message about find-tag being (supposedly) > obsoleted by xref-find-definitions as of Emacs version 25.1, Does it really say that `find-tag' is "obsolete"? Ah, yes it does. I'm surprised. That's too bad. We couldn't just have *added* the `xref' stuff, as an alternative? Bad enough that keys bound by default to other commands were immediately sacrificed to xref, but deprecating those other commands? > 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. Dommage. On n'arrete pas le progres... From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions doesn't; bug? Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Sep 2017 23:11:01 +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: To: Winston , 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15049986147891 (code B ref 28403); Sat, 09 Sep 2017 23:11:01 +0000 Received: (at 28403) by debbugs.gnu.org; 9 Sep 2017 23:10:14 +0000 Received: from localhost ([127.0.0.1]:58048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqotB-00023D-PE for submit@debbugs.gnu.org; Sat, 09 Sep 2017 19:10:13 -0400 Received: from mail-lf0-f48.google.com ([209.85.215.48]:36483) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqotA-000230-6l for 28403@debbugs.gnu.org; Sat, 09 Sep 2017 19:10:12 -0400 Received: by mail-lf0-f48.google.com with SMTP id m199so11659868lfe.3 for <28403@debbugs.gnu.org>; Sat, 09 Sep 2017 16:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=o4uEJzIoIUVww6A6QOLS4vcjpH/nP9pLs4LwjQrKVqE=; b=DKloTEk+Cw5GZbsVjNg/Hg5cy+6w11OxEJW/f2AXVCrMHk9tdlKpxhMM40CMkWonRc RlEcBQjBTOj5AClzcu/9z+I29ol6WLf/1PjqvIX7SRRd2yMvnv/hKWN5JAPXYU4FHgbg wCVfvwQ1k3z4P+NhcAI5NvvJH3gsW4nA43FXoq5qyArqQOzowAWPzdk1UsmpVERAjU7b KUINS54ffrTbf2yYWW+0DHtcv9FJY5JtT2/2fsvWmdDxkyEDKF59Uviy7384EFmASs28 k8ngN6Ya7bBByuyHZy9PczuI0BCmrxBr6mP+FN9Jm2byby4Vwrh3+f1fR9SGlS6r8+J7 fD/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=o4uEJzIoIUVww6A6QOLS4vcjpH/nP9pLs4LwjQrKVqE=; b=aTKhvJ7U54EarTO3KNgq6yOU0wxq7qrn2XXHdYOfI2f8JAQKlA9NSgA5vSSkM/75mO 1MD/1AMK4gs474ANQbMrAW7LdAbV6WdYidZimhQb7FTvLEWlTJ8vuxekXUdAGhCrjPqZ GJPkrVpkEI9bUpOwPerTPJlAo6ix8YUnrLIz46/VaBF1VHKsifZQScbiuExD8ZWQ9hh2 f3VbPv6wsz/7Cia+ZnclszrDxDaFopdR1IhGVF+QvHP4f+QLRp/cfl1GEzVtDhWvvKTN AXGxQlD1dRGtCMlDWWLG8jofCRDeOidhY08Y1eBk7R+vWF949xmmxUj9q0IimbLJ8J5s L8bw== X-Gm-Message-State: AHPjjUjtSZjTC5NTLzSCORw6HxJVJTmFoxSUvr090pA8lARMxw4ZYFVL TYe1vYcgiKqJIhgmo0c= X-Google-Smtp-Source: ADKCNb4LtlDoxxsSRY7l21HGzIhos4vjKXVJqySMz+ku7qnTL6bNcYrKLNgMIHh2CcAGuTr8q02k6g== X-Received: by 10.46.19.17 with SMTP id 17mr2339375ljt.31.1504998605846; Sat, 09 Sep 2017 16:10:05 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id g11sm982865lji.95.2017.09.09.16.10.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Sep 2017 16:10:04 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> From: Dmitry Gutov Message-ID: <296550ac-ab86-a7a5-59a5-bc906886a65e@yandex.ru> Date: Sun, 10 Sep 2017 02:10:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <201709092240.v89MeFUo014854@psr.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/10/17 1:39 AM, Winston 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". [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.48 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.48 listed in dnsbl.sorbs.net] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.48 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/10/17 1:39 AM, Winston 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". [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.48 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.48 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.48 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/10/17 1:39 AM, Winston 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". Which program are you generating TAGS with? Is it etags that comes with Emacs? xref-find-definitions is somewhat stricter about its input than find-tag. What does the entry for this function inside TAGS look like? You can paste it into the reply. The TAGS format is close to plain text. I'm guessing it looks like: name _ARGS1( which is an "implicit tag name" entry for "_ARGS1", but not for "name". IOW, etags doesn't understand macros. > 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). From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> 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: To: Dmitry Gutov , 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150501180927101 (code B ref 28403); Sun, 10 Sep 2017 02:51:02 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 02:50:09 +0000 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 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 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) 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) Message-Id: <201709100250.v8A2o6nL015568@psr.com> Date: Sat, 9 Sep 2017 22:50 EDT From: Winston MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Sep 2017 09:02: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: To: Winston , 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150503407929632 (code B ref 28403); Sun, 10 Sep 2017 09:02:03 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 09:01:19 +0000 Received: from localhost ([127.0.0.1]:58344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqy7D-0007hs-Fa for submit@debbugs.gnu.org; Sun, 10 Sep 2017 05:01:19 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:34986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqy7B-0007he-Bu for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 05:01:17 -0400 Received: by mail-lf0-f65.google.com with SMTP id c8so2720726lfe.2 for <28403@debbugs.gnu.org>; Sun, 10 Sep 2017 02:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xP6I0/PhsCT79Qa5NLAA4NkNmiho9YGcvJa2nj59At8=; b=rXdKo7IQvg8DZJBiAOcp48lwUglnM440XqxS683mLADqA5M3eT1jMJKZFQGPnx7d3Q kovhxJRYn+23u28i83aekl+ii2lPQp4No/9ShQSTgXdqYm3awquy7NQYFViHTyPPBS2k IOqtu+lIHJlIOZ6mtfXpbSLG0R4WYuSwr89fdQukXhypKSYAHyUgM6hS4VBxR4oTWVUJ Eu0xR8de4OMhlCL3YdMKtXtoX2NBcb4dFEWwOplsB/MXrs603LApELpS3MR0KuPyQ++x 0Gqnvg+/2t/BXBhVYqPtWyIJxTO/8/w6+rxkJpV3ncVyuym7Nnpotht/rIiWjWevGLZJ asYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xP6I0/PhsCT79Qa5NLAA4NkNmiho9YGcvJa2nj59At8=; b=WJmBlID0RB8lLxuG7cr/kOKfWg/TehsckBB/Qrugt6U4SbdIzLfo3ZWUpZHuYXKr5W JadHUZwVixw9SipRkxhsEc5MGEJUFbUPIe+P5Td+w98sllEltwjwqdzN0a+1PH5pqhgJ toNq3OYG4M31Z1IxUMKkNC6/TkrD+fis4APSSUfMpP2G+kAsmg964C3+nx5BVpRowPvf xssQCz7HuOLN6qMNRT+cMPb53rMo9kFe0GZT4vW4XMO42XbOaASF42lKES6fGY4HcGub hw2BWoR7eA2UTRJX65yRtfD6lNA9tVDZ5JNwbI8r0OrCuw0LIigq9VbZ+NuIxMZZosiC ERTw== X-Gm-Message-State: AHPjjUjiwUljSJj3ViRUJ68z62kSkjUg/6ojotpZDV6UtYh41+D+g6p9 VHoUeF3ZFDTtrZjutkY= X-Google-Smtp-Source: AOwi7QCaA8IVNxLsaUz8ffSNO2iQU58nq11nNoXXW0bNP88egTgRDLfnon07+n/arq4+1p/AUAemKA== X-Received: by 10.25.143.199 with SMTP id s68mr2308762lfk.143.1505034070930; Sun, 10 Sep 2017 02:01:10 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id g21sm1194236lje.52.2017.09.10.02.01.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Sep 2017 02:01:09 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> From: Dmitry Gutov Message-ID: <85628b7a-3be1-0bea-57d5-1346589f7b8a@yandex.ru> Date: Sun, 10 Sep 2017 12:01:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <201709100250.v8A2o6nL015568@psr.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/10/17 5:49 AM, Winston wrote: > Yes, and "etags --version" prints: etags (GNU Emacs 25.2) Thanks. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.65 listed in dnsbl.sorbs.net] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.65 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.65 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/10/17 5:49 AM, Winston wrote: > Yes, and "etags --version" prints: etags (GNU Emacs 25.2) Thanks. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.65 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.65 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.65 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 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). From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Sep 2017 14:30:01 +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: To: Winston Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050537861940 (code B ref 28403); Sun, 10 Sep 2017 14:30:01 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 14:29:46 +0000 Received: from localhost ([127.0.0.1]:59486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr3F4-0000VE-H7 for submit@debbugs.gnu.org; Sun, 10 Sep 2017 10:29:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52301) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr3F2-0000Uz-QE for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 10:29:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dr3Eu-0002sO-Fr for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 10:29:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dr3Eu-0002sD-Cg; Sun, 10 Sep 2017 10:29:36 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2732 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dr3Es-00085y-GJ; Sun, 10 Sep 2017 10:29:36 -0400 Date: Sun, 10 Sep 2017 17:29:32 +0300 Message-Id: <837ex6vd83.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <201709100250.v8A2o6nL015568@psr.com> (message from Winston on Sat, 9 Sep 2017 22:50 EDT) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Sat, 9 Sep 2017 22:50 EDT > From: Winston > > 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 Thanks. 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. > > 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). Dmitry, how about providing a more user-friendly customization to that effect? As a "fire escape"? > 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. We want to make xref as good as the features it replaces and better. It is already better in several areas: it is much more accurate (so many times lands you right on the spot, whereas find-tag might require to go sequentially through several alternatives), and in the rare cases where there are more than a single candidate, it allows you to select the right one much faster. We would like to solve any remaining problems, and that will be much harder if people don't report those problems to us. 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. Thanks. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> 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 14:53:01 +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: To: Dmitry Gutov , 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050551644074 (code B ref 28403); Sun, 10 Sep 2017 14:53:01 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 14:52:44 +0000 Received: from localhost ([127.0.0.1]:59497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr3bI-00013e-FW for submit@debbugs.gnu.org; Sun, 10 Sep 2017 10:52:44 -0400 Received: from mail.psr.com ([67.212.42.216]:22951 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr3bG-00013R-Ep for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 10:52:43 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8AEqhgl018099 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 10:52:43 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8AEqhOw018098; Sun, 10 Sep 2017 10:52:43 -0400 (EDT) (envelope-from wbe) Message-Id: <201709101452.v8AEqhOw018098@psr.com> Date: Sun, 10 Sep 2017 10:52 EDT From: Winston X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Dmitry kindly replied: > 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. and previously replied: >>> 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 I'd replied: >> 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? As my reply indicated, I had not, mainly because of your warning that that solution would cause false positives. However, I just tried it now, and, at least initially, it seems to do fine, so I'm now willing to switch over. If you haven't already done so, it's probably worth documenting this solution somewhere so that others converting from find-tag can find this fix via search (Google or otherwise). Thanks! I'll now consider this bug solved. -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> 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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150506804423245 (code B ref 28403); Sun, 10 Sep 2017 18:28:03 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 18:27:24 +0000 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 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 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) 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) Message-Id: <201709101827.v8AIRMse018692@psr.com> Date: Sun, 10 Sep 2017 14:27 EDT From: Winston MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> 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 19:07: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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150507036826885 (code B ref 28403); Sun, 10 Sep 2017 19:07:02 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 19:06:08 +0000 Received: from localhost ([127.0.0.1]:59689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr7YW-0006zY-DH for submit@debbugs.gnu.org; Sun, 10 Sep 2017 15:06:08 -0400 Received: from mail.psr.com ([67.212.42.216]:23284 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr7YT-0006z3-Bl for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 15:06:07 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8AJ63XT018860 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 15:06:03 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8AJ63RK018859; Sun, 10 Sep 2017 15:06:03 -0400 (EDT) (envelope-from wbe) Message-Id: <201709101906.v8AJ63RK018859@psr.com> Date: Sun, 10 Sep 2017 15:06 EDT From: Winston MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli kindly replied: > 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, Just thought... (setq etags-leading-function-names true) ? to indicate that function names are always the first thing on their definition lines? -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Sep 2017 19:11:01 +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: To: Winston Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150507061227228 (code B ref 28403); Sun, 10 Sep 2017 19:11:01 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 19:10:12 +0000 Received: from localhost ([127.0.0.1]:59694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr7cR-000755-TC for submit@debbugs.gnu.org; Sun, 10 Sep 2017 15:10:12 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr7cQ-00074t-Al for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 15:10:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dr7cI-0005gH-4R for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 15:10:05 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dr7cI-0005gD-0e; Sun, 10 Sep 2017 15:10:02 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3576 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dr7c7-00012y-4H; Sun, 10 Sep 2017 15:10:01 -0400 Date: Sun, 10 Sep 2017 22:09:28 +0300 Message-Id: <83tw0atlp3.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <201709101827.v8AIRMse018692@psr.com> (message from Winston on Sun, 10 Sep 2017 14:27 EDT) References: <201709101827.v8AIRMse018692@psr.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Sun, 10 Sep 2017 14:27 EDT > From: Winston > Cc: dgutov@yandex.ru, 28403@debbugs.gnu.org > > 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). [...] Thanks, this confirms my suspicion: as Dmitry says, etags produces TAGS for the _ARG# macros, and doesn't see the function names. So the fact that find-tag finds the functions is just sheer luck: it falls back to more or less simple text search, so it can find anything you have in the TAGS tables. To have xref-find-definitions work in this case, you need to help etags a bit, see below. > > [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). Again, it seems to work well in your case because you take special precautions to avoid producing symbols that would generate false positives. But that is a fragile solution, IMO. > > 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. :) Good, because here's how I suggest you invoke etags to solve the problems with the _ARGS# macros: etags --regex="/[ \t]*\([^ \t]+\)[ \t]+_ARGS/\1/" ... (replace "..." with all the other arguments you normally give when you invoke etags). This will tell etags to tag the symbols immediately preceding the _ARGS# macro invocations _in_addition_ to what it already does. Then you can use xref-find-definitions in its default configuration, and it will find your functions. (The --regexp switch to etags is described in the Emacs manual.) From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> 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 19:11: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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150507063627264 (code B ref 28403); Sun, 10 Sep 2017 19:11:02 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 19:10:36 +0000 Received: from localhost ([127.0.0.1]:59697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr7cq-00075g-8o for submit@debbugs.gnu.org; Sun, 10 Sep 2017 15:10:36 -0400 Received: from mail.psr.com ([67.212.42.216]:23316 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr7co-00075U-3d for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 15:10:34 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8AJAYIU018918 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 15:10:34 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8AJAYs8018917; Sun, 10 Sep 2017 15:10:34 -0400 (EDT) (envelope-from wbe) Message-Id: <201709101910.v8AJAYs8018917@psr.com> Date: Sun, 10 Sep 2017 15:10 EDT From: Winston MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli kindly replied: > 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, Just thought... (setq etags-leading-function-names true) ? to indicate that function names are always the first thing on their definition lines? The idea would be to have something one puts in a C file's Local Variables section, when such style is used. -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> 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 20:13:01 +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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150507432832613 (code B ref 28403); Sun, 10 Sep 2017 20:13:01 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 20:12:08 +0000 Received: from localhost ([127.0.0.1]:59752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr8aO-0008Tx-IX for submit@debbugs.gnu.org; Sun, 10 Sep 2017 16:12:08 -0400 Received: from mail.psr.com ([67.212.42.216]:23422 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr8aM-0008TS-BD for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 16:12:06 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8AKC5Y1019101 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 16:12:05 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8AKC49v019100; Sun, 10 Sep 2017 16:12:04 -0400 (EDT) (envelope-from wbe) Message-Id: <201709102012.v8AKC49v019100@psr.com> Date: Sun, 10 Sep 2017 16:12 EDT From: Winston X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli suggested: > ... here's how I suggest you invoke etags to solve the > problems with the _ARGS# macros: > > etags --regex="/[ \t]*\([^ \t]+\)[ \t]+_ARGS/\1/" ... I don't think that quite works because it doesn't flush the number. Probably more like: etags --regex="/[ \t]*\([^ \t]+\)[ \t]+_ARGS[0-9]+/\1/" ... but since, in this particular case, there's never any leading space on the line before a function name and the code doesn't use tabs on those lines, maybe etags --regex="/\([^ ]+\) +_ARGS[0-9]+/\1/" ... would work as well? (Does regex have an implicit '^'? If not, I'll use an explicit one.) > This will tell etags to tag the symbols immediately preceding the > _ARGS# macro invocations _in_addition_ to what it already does. [Too bad etags doesn't have a way of doing "s/[ \t]+_ARGS[0-9]*//" on the lines it normally finds...] > Then you can use xref-find-definitions in its default configuration, > and it will find your functions. OK. I like that approach better than having to do the setq, especially since putting a suitable etags command in a makefile is easy. That also has the benefit of tying the fix to the code written in that style, rather than making a global change that would affect other code I work on. Thanks! -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> 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 21:20:01 +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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050783906712 (code B ref 28403); Sun, 10 Sep 2017 21:20:01 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 21:19:50 +0000 Received: from localhost ([127.0.0.1]:59827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr9dt-0001kA-9u for submit@debbugs.gnu.org; Sun, 10 Sep 2017 17:19:50 -0400 Received: from mail.psr.com ([67.212.42.216]:23499 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr9dr-0001jv-Pm for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 17:19:48 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8ALJjS2019298 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 17:19:45 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8ALJipg019297; Sun, 10 Sep 2017 17:19:44 -0400 (EDT) (envelope-from wbe) Message-Id: <201709102119.v8ALJipg019297@psr.com> Date: Sun, 10 Sep 2017 17:19 EDT From: Winston MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Progress, but it's not working as expected. I ran etags --regex="/\([^ ]+\) +_ARGS[0-9]+/\1/" ... It added lines of the form: foo1 _ARGS2^?foo1^A341,12188 foo2 _ARGS1^?foo2^A368,12664 to TAGS, which looked reasonable. I then started up a fresh Emacs that uses xref-find-definitions instead of find-tag, and that did not have the setq change. The results surprised me: * Find "foo1" or "foo2" (complete names) worked, both when typed in and when extracting a name near (point). * Find "foo" (partial name) didn't: rather than creating a window with the alternatives, it failed with "No definitions found for: foo". find-tag given the same string "foo" went to the first one. xref-find-definitions with Dmitry's suggested change also worked (yesterday, without the special etags --regex TAGS, popping up a window with the alternatives). Any suggestions? -WBE P.S. Also, I'm finding it mildly annoying that xref-find-definitions, when next to just about any word, including text in comments, tries immediately to go to that word as a tag rather than prompting me for a name with the word as the default, as find-tag did. That means I'll have to remember to use my {arg} key fairly often to tell it "don't do that, prompt me." Is there an "always prompt" option, or do I need to write a trivial wrapper function? From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Sep 2017 21:36:01 +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: To: Winston , Eli Zaretskii Cc: 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050793128087 (code B ref 28403); Sun, 10 Sep 2017 21:36:01 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 21:35:12 +0000 Received: from localhost ([127.0.0.1]:59839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr9sl-00026N-Uu for submit@debbugs.gnu.org; Sun, 10 Sep 2017 17:35:12 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:38598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dr9sk-000269-Hk for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 17:35:10 -0400 Received: by mail-lf0-f68.google.com with SMTP id m199so3146497lfe.5 for <28403@debbugs.gnu.org>; Sun, 10 Sep 2017 14:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DY9X8sOqJ8Yth7jm0qx1pu58GLqJrfHWd2i3/LkGBT4=; b=LPuS1MaYe4yTCpQjp24NNBoBVb/7pesh1Y3c6l/1l7Vs90pTGiengzTZoVKtYS4b+O JVZer6G28Zivuf33px4JENgfaZF+jr8Jb+DeHI414jIGppXMmxeXvwNPsCSlgUNgzguv oj8SP37F8ewaZTfqTYGe88j63h0WZmAzz9GzpxUuLmawKBmYbhZCeud5oM1D9zbJSZD7 X1HQ0wrbWXC3RZQUxesaPzwfCedZtdc30mu3GZ82ZZzbfLjW7dFw0hcFZxrckaOAA7Sw 6+FGzt23OuPpzHrgAcZEhui2vadTu0MtKlNslPIBn0HOfHO/163BD9veuGsEDJKASLtn BROQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DY9X8sOqJ8Yth7jm0qx1pu58GLqJrfHWd2i3/LkGBT4=; b=oIFJLS82lcMYzlgfbHMhnw1mNAdCEHZu+u4bRo1JV5CbACEXRzvsKc3A8uCm1Snl9z iMNMcqQ/13EKuO1qTzlCnxUM0USQd1M81pyWoGzKKktVmL6zly5h6SyTt9F0+0PyRLqD jvwiodpowMCK06IM+3vvKiOZ+wTUa9fZo4WzHrhzblyJJsqZwZZJGfBR6MrgZ5RSsut0 t1YVI5/SA93/Qm/yun8ixWkhNPTIz77LX4DzhPWTiV+lUSnGwiT2oWYu0JO20Ayk2w5A QvNQTgoy4SIWrBKrerQqWO52z+vYldeSKwZgU+acHoL39Azbe+m7sYAqg3k3mMqTu/FO USVQ== X-Gm-Message-State: AHPjjUjywvSV8RWk5pxwOydPrwbBQTqpeGfyb1IAxFxYYEwM3cUqkS71 zEqpg8fqz27QtyUrM1U= X-Google-Smtp-Source: AOwi7QCps/DfxrmJi/EeJl3/PVRPOPN5SPieszfwY/rEUNEMsdM2kST/L3di2TXo1mqIbIlkIoKlCw== X-Received: by 10.46.83.22 with SMTP id h22mr2949712ljb.96.1505079304104; Sun, 10 Sep 2017 14:35:04 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id y17sm1462383lje.31.2017.09.10.14.35.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Sep 2017 14:35:03 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> <201709102119.v8ALJipg019297@psr.com> From: Dmitry Gutov Message-ID: Date: Mon, 11 Sep 2017 00:35:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <201709102119.v8ALJipg019297@psr.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/11/17 12:18 AM, Winston wrote: > * Find "foo" (partial name) didn't: rather than creating a window with > the alternatives, it failed with "No definitions found for: foo". That is because 'foo' is not defined in that file. And showing either of the two lines as a match for it would be a false positive. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.68 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.68 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.68 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/11/17 12:18 AM, Winston wrote: > * Find "foo" (partial name) didn't: rather than creating a window with > the alternatives, it failed with "No definitions found for: foo". That is because 'foo' is not defined in that file. And showing either of the two lines as a match for it would be a false positive. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.68 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.68 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.68 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/11/17 12:18 AM, Winston wrote: > * Find "foo" (partial name) didn't: rather than creating a window with > the alternatives, it failed with "No definitions found for: foo". That is because 'foo' is not defined in that file. And showing either of the two lines as a match for it would be a false positive. You should probably use project-find-regexp. Or use C-u M-x xref-find-definitions with completion: you type 'foo', TAB, then see the available tags that start with that string, pick one of them, and see its definitions. > find-tag given the same string "foo" went to the first one. > xref-find-definitions with Dmitry's suggested change also worked > (yesterday, without the special etags --regex TAGS, popping up a > window with the alternatives). > > Any suggestions? Just what I suggested before. But this problem is not related to your use of macros anymore. > -WBE > > P.S. Also, I'm finding it mildly annoying that xref-find-definitions, > when next to just about any word, including text in comments, tries > immediately to go to that word as a tag rather than prompting me > for a name with the word as the default, as find-tag did. That > means I'll have to remember to use my {arg} key fairly often to > tell it "don't do that, prompt me." Is there an "always prompt" > option, or do I need to write a trivial wrapper function? You can customize xref-prompt-for-identifier to t. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Sep 2017 21:45:01 +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: To: Eli Zaretskii , Winston Cc: 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050798438845 (code B ref 28403); Sun, 10 Sep 2017 21:45:01 +0000 Received: (at 28403) by debbugs.gnu.org; 10 Sep 2017 21:44:03 +0000 Received: from localhost ([127.0.0.1]:59849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drA1L-0002Ia-24 for submit@debbugs.gnu.org; Sun, 10 Sep 2017 17:44:03 -0400 Received: from mail-lf0-f49.google.com ([209.85.215.49]:37612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drA1I-0002Hz-Rr for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 17:44:01 -0400 Received: by mail-lf0-f49.google.com with SMTP id 80so14424088lfy.4 for <28403@debbugs.gnu.org>; Sun, 10 Sep 2017 14:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xHKR6KBmMsa7SMoNZ2p9mjwR5XXRAvPNQQfY7ASpLUs=; b=hxPYac7H3s+hwOQ/9vGw29m2/u8QeLhM0syjHz1QUgea+atEELwI9Q11OonzPTZCoe fg0U+l0dr4Wb0YlkPBTZig3Sfv199rPQFrbM0nJGSx2K0gcM0Ad619L6MecsiiKQKuEj 7ePhUcHgqOyeJQ9+InxCngXminpum0scoel96wAAiRy5qQXPqpJKMqJDhLzmyzgaCHm6 fEhIT7Bed630eRa1/4dQ3/uilVLytFOw0IHIg6Y9RQ98x1XMYOJzximNpXLCrsS8vp3A QAnwi79nZSzY+VcQ5xMvSpJKqQcEGIOw0EcMDQc5BXKa2Y6E7+jHqGqLHS42Ceeij94K vCRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xHKR6KBmMsa7SMoNZ2p9mjwR5XXRAvPNQQfY7ASpLUs=; b=igJclUpU+aBJNkVeKpBsjpL8YmPJDrKbkclo74ZmaxJC1oZbfZPqTN8fapghJJxvUD XQRC3KH7aqt5TrK59bfywa4Yv8cS5B/aSEFdeNdpcczU04dJQd81JSG8rZ6j6zPhb5vL m5/kXO5unuZcohwYRo9GcT+AdMUSK9pXyevTYHemTjvxXQdS29UcHpvu2m6fpL9nuXtA 1Njyiil3RFArBLmxm7UuB8IktYgpoCjVrV9VG81kjGOkKnIVFqZRzWtKwzpr2O4TXjKs 7B905R/yvLTIRU1CInLPxOT66M0Pdioq/A6ufWlx02joPA+9En/w7rDS8it2GQjNo1rB XzqA== X-Gm-Message-State: AHPjjUhIscDb54MaJdQz6Vr4Ef4IHvzM2HoYxVZal2rNiHaW2jvxYPj5 4Cv58W4Rn/AazSRueYY= X-Google-Smtp-Source: ADKCNb5RpS/0HBfKBFeo+20dMPRp7Zdmc3DPb4HHKKWb/NCLL/zH23TJJRy5VnVscZ5jXBrdU1pkoQ== X-Received: by 10.46.25.23 with SMTP id p23mr1743784lje.37.1505079834571; Sun, 10 Sep 2017 14:43:54 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id h64sm445507ljf.36.2017.09.10.14.43.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Sep 2017 14:43:53 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Mon, 11 Sep 2017 00:43:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <837ex6vd83.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/10/17 5:29 PM, Eli Zaretskii wrote: >>> 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). > > Dmitry, how about providing a more user-friendly customization to that > effect? As a "fire escape"? [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.49 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.49 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.49 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/10/17 5:29 PM, Eli Zaretskii wrote: >>> 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). > > Dmitry, how about providing a more user-friendly customization to that > effect? As a "fire escape"? [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.49 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.49 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.49 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/10/17 5:29 PM, Eli Zaretskii wrote: >>> 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). > > Dmitry, how about providing a more user-friendly customization to that > effect? As a "fire escape"? We can turn etags-xref-find-definitions-tag-order into a defcustom, with descriptions of what every possible element means. Problems: 1) I have hard time imagining how we're going to have descriptions for both tag-exact-match-p and tag-implicit-name-match-p that are different and make sense to the user. 2) The user will have to find out about etags-xref-find-definitions-tag-order first anyway. Or we could add a custom variable to xref with a higher-level meaning... that would require support from backends, then. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 02:32:01 +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: To: Winston Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050970809329 (code B ref 28403); Mon, 11 Sep 2017 02:32:01 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 02:31:20 +0000 Received: from localhost ([127.0.0.1]:60118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drEVM-0002QP-GI for submit@debbugs.gnu.org; Sun, 10 Sep 2017 22:31:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drEVK-0002QD-TG for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 22:31:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drEVB-0003hy-Ca for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 22:31:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drEVB-0003hp-9i; Sun, 10 Sep 2017 22:31:09 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3960 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drEVA-0002Bv-O5; Sun, 10 Sep 2017 22:31:09 -0400 Date: Mon, 11 Sep 2017 05:31:20 +0300 Message-Id: <83mv62t18n.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <201709102012.v8AKC49v019100@psr.com> (message from Winston on Sun, 10 Sep 2017 16:12 EDT) References: <201709102012.v8AKC49v019100@psr.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Sun, 10 Sep 2017 16:12 EDT > From: Winston > Cc: dgutov@yandex.ru, 28403@debbugs.gnu.org > > Eli suggested: > > ... here's how I suggest you invoke etags to solve the > > problems with the _ARGS# macros: > > > > etags --regex="/[ \t]*\([^ \t]+\)[ \t]+_ARGS/\1/" ... > > I don't think that quite works It worked with your example. > etags --regex="/\([^ ]+\) +_ARGS[0-9]+/\1/" ... > > would work as well? As long as you understand the principles, it's in your hands. > Does regex have an implicit '^'? Yes (as explained in the manual). > [Too bad etags doesn't have a way of doing "s/[ \t]+_ARGS[0-9]*//" on > the lines it normally finds...] Why do you need that? > OK. I like that approach better than having to do the setq, > especially since putting a suitable etags command in a makefile is easy. > That also has the benefit of tying the fix to the code written in that > style, rather than making a global change that would affect other code I > work on. Right. I guess we can now close the bug report? From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 02:35:01 +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: To: Winston Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050972939621 (code B ref 28403); Mon, 11 Sep 2017 02:35:01 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 02:34:53 +0000 Received: from localhost ([127.0.0.1]:60122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drEYn-0002V7-2Y for submit@debbugs.gnu.org; Sun, 10 Sep 2017 22:34:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drEYl-0002Uw-Vw for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 22:34:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drEYc-0005Gw-PV for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 22:34:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drEYc-0005Gq-Ml; Sun, 10 Sep 2017 22:34:42 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3962 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drEYc-0006IW-7U; Sun, 10 Sep 2017 22:34:42 -0400 Date: Mon, 11 Sep 2017 05:34:54 +0300 Message-Id: <83lglmt12p.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <201709102119.v8ALJipg019297@psr.com> (message from Winston on Sun, 10 Sep 2017 17:19 EDT) References: <201709102119.v8ALJipg019297@psr.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Sun, 10 Sep 2017 17:19 EDT > From: Winston > Cc: dgutov@yandex.ru, 28403@debbugs.gnu.org > > * Find "foo1" or "foo2" (complete names) worked, both when typed in and > when extracting a name near (point). > > * Find "foo" (partial name) didn't: rather than creating a window with > the alternatives, it failed with "No definitions found for: foo". > find-tag given the same string "foo" went to the first one. As expected. You have bad habits from using find-tag. With xref, you need to do "M-. foo TAB". > P.S. Also, I'm finding it mildly annoying that xref-find-definitions, > when next to just about any word, including text in comments, tries > immediately to go to that word as a tag rather than prompting me > for a name with the word as the default, as find-tag did. That > means I'll have to remember to use my {arg} key fairly often to > tell it "don't do that, prompt me." Is there an "always prompt" > option, or do I need to write a trivial wrapper function? I got used to this very quickly, but if you don't want to try, write your wrapper. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 02:39: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: To: Dmitry Gutov Cc: wbe@psr.com, 28403@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15050975099937 (code B ref 28403); Mon, 11 Sep 2017 02:39:02 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 02:38:29 +0000 Received: from localhost ([127.0.0.1]:60126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drEcH-0002aC-Jj for submit@debbugs.gnu.org; Sun, 10 Sep 2017 22:38:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drEcF-0002a0-Oh for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 22:38:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drEc7-00070z-BS for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 22:38:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drEc7-00070v-8T; Sun, 10 Sep 2017 22:38:19 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3963 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drEc6-0003LZ-MN; Sun, 10 Sep 2017 22:38:19 -0400 Date: Mon, 11 Sep 2017 05:38:30 +0300 Message-Id: <83k216t0wp.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Dmitry Gutov on Mon, 11 Sep 2017 00:43:51 +0300) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 28403@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 11 Sep 2017 00:43:51 +0300 > > > Dmitry, how about providing a more user-friendly customization to that > > effect? As a "fire escape"? > > We can turn etags-xref-find-definitions-tag-order into a defcustom, with > descriptions of what every possible element means. I rather had in mind a variable with a few simple values, and a :set function which would put what's needed into etags-xref-find-definitions-tag-order. IOW, hide the complexity from the UI. > 1) I have hard time imagining how we're going to have descriptions for > both tag-exact-match-p and tag-implicit-name-match-p that are different > and make sense to the user. Simple values with solve that. For starters, we could use just 2: 'exact' and 'fuzzy'. > 2) The user will have to find out about > etags-xref-find-definitions-tag-order first anyway. Will be solved by having the defcustom under a more descriptive name. And since this is a "fire escape", it will be needed relatively rarely. The point is to have it, so we could point users to it. > Or we could add a custom variable to xref with a higher-level meaning... Yes. > that would require support from backends, then. Why? From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> In-Reply-To: <201709092240.v89MeFUo014854@psr.com> Resent-From: Winston Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 03:20: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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150509994913499 (code B ref 28403); Mon, 11 Sep 2017 03:20:02 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 03:19:09 +0000 Received: from localhost ([127.0.0.1]:60176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drFFc-0003Vf-Uk for submit@debbugs.gnu.org; Sun, 10 Sep 2017 23:19:09 -0400 Received: from mail.psr.com ([67.212.42.216]:23875 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drFFb-0003VT-Ow for 28403@debbugs.gnu.org; Sun, 10 Sep 2017 23:19:08 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8B3J798020371 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Sep 2017 23:19:07 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8B3J7VP020370; Sun, 10 Sep 2017 23:19:07 -0400 (EDT) (envelope-from wbe) Message-Id: <201709110319.v8B3J7VP020370@psr.com> Date: Sun, 10 Sep 2017 23:19 EDT From: Winston X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) I wrote: >> * Find "foo" (partial name) didn't: ... Eli replied: > With xref, you need to do "M-. foo TAB". Ah! OK. Yes, that worked. [My key bindings are entirely different, but I got the idea. :) ] -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> In-Reply-To: <201709092240.v89MeFUo014854@psr.com> Resent-From: Winston Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 04:06:01 +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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150510275917506 (code B ref 28403); Mon, 11 Sep 2017 04:06:01 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 04:05:59 +0000 Received: from localhost ([127.0.0.1]:60202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drFyw-0004YI-Q8 for submit@debbugs.gnu.org; Mon, 11 Sep 2017 00:05:58 -0400 Received: from mail.psr.com ([67.212.42.216]:23925 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drFyu-0004Y5-R2 for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 00:05:57 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8B45wZ2020653 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Sep 2017 00:05:58 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8B45wO3020652; Mon, 11 Sep 2017 00:05:58 -0400 (EDT) (envelope-from wbe) Message-Id: <201709110405.v8B45wO3020652@psr.com> Date: Mon, 11 Sep 2017 00:05 EDT From: Winston X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli suggested: >>> etags --regex="/[ \t]*\([^ \t]+\)[ \t]+_ARGS/\1/" ... and in reply to my changes said: > It worked with your example. Yes. The difference is a small one: "_ARGS[0-9]" only matches function definition lines, while using only "_ARGS" will also match declarations. >> [Too bad etags doesn't have a way of doing "s/[ \t]+_ARGS[0-9]*//" on >> the lines it normally finds...] > Why do you need that? The idea was that instead of cluttering up the TAGS file with two lines for every tag, such as foo _ARGS2^?foo^A50,100 foo _ARGS2(^?50,100 as a result of using --regex, a post edit that allowed one to do "s/[ \t]+_ARGS[0-9]*//" could simply remove the _ARGS2 part and reduce the default etags line to: foo(^?50,100 thus (I'm guessing) clarifying things a different way. -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> In-Reply-To: <201709092240.v89MeFUo014854@psr.com> Resent-From: Winston Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 04:12: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: To: Dmitry Gutov , Eli Zaretskii Cc: 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150510309017981 (code B ref 28403); Mon, 11 Sep 2017 04:12:02 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 04:11:30 +0000 Received: from localhost ([127.0.0.1]:60208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drG4I-0004fx-DT for submit@debbugs.gnu.org; Mon, 11 Sep 2017 00:11:30 -0400 Received: from mail.psr.com ([67.212.42.216]:23943 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drG4G-0004fk-Bh for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 00:11:28 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8B4BTbX020697 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Sep 2017 00:11:29 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8B4BTdT020696; Mon, 11 Sep 2017 00:11:29 -0400 (EDT) (envelope-from wbe) Message-Id: <201709110411.v8B4BTdT020696@psr.com> Date: Mon, 11 Sep 2017 00:11 EDT From: Winston X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) [Eli also pointed out that TAB is the way to see possible completions for a tag string. It worked. Thanks to both of you.] I asked: >> Is there an "always prompt" option, or do I need to write a trivial >> wrapper function? Dmitry kindly replied: > You can customize xref-prompt-for-identifier to t. Hooray! Thanks! -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> In-Reply-To: <201709092240.v89MeFUo014854@psr.com> Resent-From: Winston Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 05:03: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: To: Eli Zaretskii Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150510618122464 (code B ref 28403); Mon, 11 Sep 2017 05:03:02 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 05:03:01 +0000 Received: from localhost ([127.0.0.1]:60237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drGs8-0005qG-Oe for submit@debbugs.gnu.org; Mon, 11 Sep 2017 01:03:00 -0400 Received: from mail.psr.com ([67.212.42.216]:23967 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drGs7-0005q4-SG for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 01:03:00 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8B531YM020854 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Sep 2017 01:03:01 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8B531g1020853; Mon, 11 Sep 2017 01:03:01 -0400 (EDT) (envelope-from wbe) Message-Id: <201709110503.v8B531g1020853@psr.com> Date: Mon, 11 Sep 2017 01:02 EDT From: Winston X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Eli asked: > I guess we can now close the bug report? >From my standpoint, yes. However, since xref-find-definitions is not a drop-in replacement for find-tag (differences incl. find partial name differs, goes to the string at (point) without prompting, etc.), I probably won't be the last person running into the differences. Perhaps the simplest solution is to expand the documentation section of xref-find-definitions with text such as the following (corrected for anything I've got wrong below). :-) ---------- xref-find-definitions differs from find-tag several ways: * find-tag always prompted for a name, with the string at (point) as the default name. With no argument, xref-find-definitions does not prompt, and tries immediately to go to a tag with that default name. Use (setq xref-prompt-for-identifier t) to force prompting. * find-tag allowed partial names. xref-find-definitions does not. Use TAB after a partial name in a prompt for completion(s). * If find-tag finds your tags OK but xref-find-definitions does not, you may need to use --regexp with etags to help it identify the tag name. (See etags man page.) If even that doesn't help, try {whatever Dmitry and Eli decide is a good long-term easy way to add '(tag-symbol-match-p) to etags-xref-find-definitions-tag-order}. ---------- Thanks for your help! HTH, -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 08:59:01 +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: To: Eli Zaretskii Cc: wbe@psr.com, 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150512032612123 (code B ref 28403); Mon, 11 Sep 2017 08:59:01 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 08:58:46 +0000 Received: from localhost ([127.0.0.1]:60477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drKYH-00039R-Bi for submit@debbugs.gnu.org; Mon, 11 Sep 2017 04:58:46 -0400 Received: from mail-lf0-f52.google.com ([209.85.215.52]:34039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drKYF-00039F-P6 for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 04:58:44 -0400 Received: by mail-lf0-f52.google.com with SMTP id l196so16790636lfl.1 for <28403@debbugs.gnu.org>; Mon, 11 Sep 2017 01:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9nff5BiAGh/yu8Vl299qI1+4f5sbnbBQNrDxG3i5A6E=; b=Cl+smPaDs2X412ostXVdQxF9yvuVcY3q0qUmUP1FAUH2/NZ/FNZJjilGtkxHDN7oKv kcG/OdGmmpEEnCgQtjoaed9+SfiIb+SMW/Y++RF24SmG3lYNqdvk5RY5uPio30Hi96SI QkyJSijB1fD+Lz+f/9UGdxxV+h1GtpX3iuW+a8PlrCJjExaY604aTIW9lHJfbxZsg0pK YDw0lsr7Fjcm7ZNn/CKK2H9afiFm4eP07DYVKhB3elm8LlneEGJ+cfI8cJAiMNTjfvAW U4atPEeUkLANfzd0Ol800YXKhVMZEte5qolfH846FGAaTn74F1DYtrdGTTKGJqmEAfOu /4gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9nff5BiAGh/yu8Vl299qI1+4f5sbnbBQNrDxG3i5A6E=; b=kWEth2lCNYf0+I/GHokXz0QP6RNysxPyJt/W0/mN52uyixG/wvwcLwrIvpObDHEyNF MHjLxijx4o7Hr2FOaZxJiKaI7jocl/HQewUktS7bcgr6H67xo74X7kDYBYTUuzMbeONc xKKx6U947m0SdS9PapHy0k2txCE9wBtJuenbfLHcisnOc4+p5pZpjBrw9mr3MP4Ng0/A EA0nIBQhb0OXEfzZsamvbyzD2zgQ7f69J389sns/lydXk9SaLGB3/QfOS+e1CkLYoG7q GqwAURNEN+Eg+IcdX8G+o3C7nMDgj08cpHHLeyx2m57wDQbZ62CvIpzE7dlzFypSZ69F jFiA== X-Gm-Message-State: AHPjjUgg+3OmC2hbQZyKtlSmaonAGVfreR2jqyqHPUyWmV7Gv648g3Zh 25asGEtFz0a+hxArpP4= X-Google-Smtp-Source: ADKCNb5Wjp3wsk8CyaICfSgpHHDjb9ADWxl/4xpN1AA99+G1pEd0P9WSl6w2lOdUKgx8p81Q3vzDjQ== X-Received: by 10.46.71.143 with SMTP id u137mr4326267lja.35.1505120317653; Mon, 11 Sep 2017 01:58:37 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id p16sm1681309lja.74.2017.09.11.01.58.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 01:58:36 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> From: Dmitry Gutov Message-ID: <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> Date: Mon, 11 Sep 2017 11:58:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <83k216t0wp.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/11/17 5:38 AM, Eli Zaretskii wrote: >> that would require support from backends, then. To make "fuzzy" work. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.52 listed in dnsbl.sorbs.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.52 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.52 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/11/17 5:38 AM, Eli Zaretskii wrote: >> that would require support from backends, then. To make "fuzzy" work. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.52 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.52 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.52 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/11/17 5:38 AM, Eli Zaretskii wrote: >> that would require support from backends, then. To make "fuzzy" work. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 14:44: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: To: Dmitry Gutov Cc: wbe@psr.com, 28403@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150514100819783 (code B ref 28403); Mon, 11 Sep 2017 14:44:02 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 14:43:28 +0000 Received: from localhost ([127.0.0.1]:33596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drPvr-000591-Ph for submit@debbugs.gnu.org; Mon, 11 Sep 2017 10:43:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drPvq-00058o-9q for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 10:43:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drPvh-0001fc-8t for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 10:43:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drPvh-0001fU-4Y; Mon, 11 Sep 2017 10:43:17 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4311 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drPvg-0000Rn-HT; Mon, 11 Sep 2017 10:43:16 -0400 Date: Mon, 11 Sep 2017 17:43:14 +0300 Message-Id: <838thlthx9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> (message from Dmitry Gutov on Mon, 11 Sep 2017 11:58:34 +0300) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: wbe@psr.com, 28403@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 11 Sep 2017 11:58:34 +0300 > > On 9/11/17 5:38 AM, Eli Zaretskii wrote: > > >> that would require support from backends, then. > > To make "fuzzy" work. It would be good to have other back-ends support that, but I don't think it's a must. First, no one said all the back-ends must distinguish between the two modes; it could even be that only one makes sense for some language. And second, I'm guess that this new method will only be useful to those who are accustomed to etags. So I think we could add this with only the etags back-end support for now, and extend it later to other back-ends if needed. Thanks. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 16:24:01 +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: To: Winston Cc: 28403@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150514701929433 (code B ref 28403); Mon, 11 Sep 2017 16:24:01 +0000 Received: (at 28403) by debbugs.gnu.org; 11 Sep 2017 16:23:39 +0000 Received: from localhost ([127.0.0.1]:33804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drRUo-0007ee-7F for submit@debbugs.gnu.org; Mon, 11 Sep 2017 12:23:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drRUn-0007eS-9e for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 12:23:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drRUe-0005Ac-6N for 28403@debbugs.gnu.org; Mon, 11 Sep 2017 12:23:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drRUe-0005AY-3C; Mon, 11 Sep 2017 12:23:28 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4491 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drRUd-0004Mh-Dx; Mon, 11 Sep 2017 12:23:27 -0400 Date: Mon, 11 Sep 2017 19:23:25 +0300 Message-Id: <83lgllrypu.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <201709110405.v8B45wO3020652@psr.com> (message from Winston on Mon, 11 Sep 2017 00:05 EDT) References: <201709110405.v8B45wO3020652@psr.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Mon, 11 Sep 2017 00:05 EDT > From: Winston > Cc: dgutov@yandex.ru, 28403@debbugs.gnu.org > > Eli suggested: > >>> etags --regex="/[ \t]*\([^ \t]+\)[ \t]+_ARGS/\1/" ... > > and in reply to my changes said: > > It worked with your example. > > Yes. The difference is a small one: "_ARGS[0-9]" only matches function > definition lines, while using only "_ARGS" will also match declarations. That's not a problem in practice, because your prototypes are laid out differently: they have more than one symbol between the line beginning and _ARGS. But never mind. > >> [Too bad etags doesn't have a way of doing "s/[ \t]+_ARGS[0-9]*//" on > >> the lines it normally finds...] > > > Why do you need that? > > The idea was that instead of cluttering up the TAGS file with two > lines for every tag, such as > > foo _ARGS2^?foo^A50,100 > foo _ARGS2(^?50,100 > > as a result of using --regex, a post edit that allowed one to do > "s/[ \t]+_ARGS[0-9]*//" could simply remove the _ARGS2 part and reduce > the default etags line to: > > foo(^?50,100 > > thus (I'm guessing) clarifying things a different way. You shouldn't worry about that (and shouldn't look at TAGS anyway). There will be extra entries there, but they should never get in your way, as long as you use xref in its default "accurate" mode. From unknown Wed Jun 25 10:53:24 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Winston Subject: bug#28403: closed (Re: bug#28403: 25.2; find-tag works, but xref-find-definitions) Message-ID: References: <83k215rxe8.fsf@gnu.org> <201709092240.v89MeFUo014854@psr.com> X-Gnu-PR-Message: they-closed 28403 X-Gnu-PR-Package: emacs Reply-To: 28403@debbugs.gnu.org Date: Mon, 11 Sep 2017 16:53:01 +0000 Content-Type: multipart/mixed; boundary="----------=_1505148781-32139-1" This is a multi-part message in MIME format... ------------=_1505148781-32139-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #28403: 25.2; find-tag works, but xref-find-definitions doesn't; bug? which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 28403@debbugs.gnu.org. --=20 28403: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D28403 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1505148781-32139-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 28403-done) by debbugs.gnu.org; 11 Sep 2017 16:52:22 +0000 Received: from localhost ([127.0.0.1]:33856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drRwc-0008La-4O for submit@debbugs.gnu.org; Mon, 11 Sep 2017 12:52:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drRwa-0008LM-9e for 28403-done@debbugs.gnu.org; Mon, 11 Sep 2017 12:52:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drRwS-0003cl-4j for 28403-done@debbugs.gnu.org; Mon, 11 Sep 2017 12:52:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drRwS-0003ch-0q; Mon, 11 Sep 2017 12:52:12 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4524 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drRwP-0006P1-TS; Mon, 11 Sep 2017 12:52:11 -0400 Date: Mon, 11 Sep 2017 19:51:59 +0300 Message-Id: <83k215rxe8.fsf@gnu.org> From: Eli Zaretskii To: Winston In-reply-to: <201709110503.v8B531g1020853@psr.com> (message from Winston on Mon, 11 Sep 2017 01:02 EDT) Subject: Re: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709110503.v8B531g1020853@psr.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 28403-done Cc: 28403-done@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Mon, 11 Sep 2017 01:02 EDT > From: Winston > Cc: dgutov@yandex.ru, 28403@debbugs.gnu.org > > Eli asked: > > I guess we can now close the bug report? > > From my standpoint, yes. Thanks, done. > xref-find-definitions differs from find-tag several ways: > * find-tag always prompted for a name, with the string at (point) as > the default name. With no argument, xref-find-definitions does not > prompt, and tries immediately to go to a tag with that default name. > Use (setq xref-prompt-for-identifier t) to force prompting. > * find-tag allowed partial names. xref-find-definitions does not. > Use TAB after a partial name in a prompt for completion(s). > * If find-tag finds your tags OK but xref-find-definitions does not, you > may need to use --regexp with etags to help it identify the tag name. > (See etags man page.) If even that doesn't help, try > {whatever Dmitry > and Eli decide is a good long-term easy way to add '(tag-symbol-match-p) > to etags-xref-find-definitions-tag-order}. Thanks. Some of this is already in the documentation, other parts will be if/when the code does what we are discussing now. ------------=_1505148781-32139-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 9 Sep 2017 22:40:30 +0000 Received: from localhost ([127.0.0.1]:58019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqoQP-0001Mq-Sk for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:30 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqoQO-0001Md-GT for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqoQI-0007ci-Hj for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:23 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34056) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dqoQI-0007ce-EU for submit@debbugs.gnu.org; Sat, 09 Sep 2017 18:40:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqoQH-00018H-38 for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 18:40:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqoQD-0007YW-5L for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 18:40:21 -0400 Received: from mail.psr.com ([67.212.42.216]:22149 helo=psr.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dqoQC-0007Vm-W1 for bug-gnu-emacs@gnu.org; Sat, 09 Sep 2017 18:40:17 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v89MeF4r014855 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Sep 2017 18:40:15 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v89MeFUo014854; Sat, 9 Sep 2017 18:40:15 -0400 (EDT) (envelope-from wbe) Message-Id: <201709092240.v89MeFUo014854@psr.com> Date: Sat, 9 Sep 2017 18:40 EDT From: Winston Subject: 25.2; find-tag works, but xref-find-definitions doesn't; bug? To: bug-gnu-emacs@gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=fixed X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) [Emacs 25.2; it looks (to me) like a regexp match pattern issue in xref.el, not an O/S issue.] Today I noticed the message about find-tag being (supposedly) obsoleted by xref-find-definitions as of Emacs version 25.1, so I tried the new command. Unfortunately, the new one failed completely on an entire class of function definitions. After some experimenting, it appears that the problem may be that xref-find-definitions only works when the function definition is of the form: name spacing* '('. 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". Changing the function definition line to name (type variable) as a test, re-running etags, and reloading TAGS, xref-find-definitions found the tag and went to it. 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. -WBE ------------=_1505148781-32139-1-- From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Sep 2017 23:41: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: To: Eli Zaretskii Cc: wbe@psr.com, 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150525963125988 (code B ref 28403); Tue, 12 Sep 2017 23:41:02 +0000 Received: (at 28403) by debbugs.gnu.org; 12 Sep 2017 23:40:31 +0000 Received: from localhost ([127.0.0.1]:36620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drun9-0006l6-Fy for submit@debbugs.gnu.org; Tue, 12 Sep 2017 19:40:31 -0400 Received: from mail-lf0-f44.google.com ([209.85.215.44]:37745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drun7-0006ku-Dj for 28403@debbugs.gnu.org; Tue, 12 Sep 2017 19:40:30 -0400 Received: by mail-lf0-f44.google.com with SMTP id 80so30166219lfy.4 for <28403@debbugs.gnu.org>; Tue, 12 Sep 2017 16:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5a+J4y1B4N7Gi+lj355WnU32L00K7Ea17Roh+a0BG4s=; b=bpNdgXd8upSQ+ZS4Eb5l7PSPrbT8UO3Pi/DNQuPJ4qu+jlSGUZ4dwPPH4pw1XiNbeT U+LEVe0vBM4304+/oRn213mr0RGgaf9tF7X9K5OedZS4sNBEkrWCG00WYSXMGa0xucac hzu76DUzL6rkciZzCV0RCTzweTMI9+qHuHQBq9ZtqHkSXsWCIqh0sL1MRdrmSOyAjvzS IEB+yxr50lB9ELXFafMd8HP1W7t4T8mzrMfYPMO34JkR4GJ9gmpDGBqe8Oc+5zka2xxj WI9AbDtzGhPN5KK7cSVG/mUYEp7rUG0GAy6oZuEwTTLP8FWsxsZek7lHx8kMsm5Empm+ 71rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5a+J4y1B4N7Gi+lj355WnU32L00K7Ea17Roh+a0BG4s=; b=CB7X2wUiRd9ii28x0nTwVlfnzm3dPDHSS+gUP/SRA3yn2xRdWNKsQPieDoPj0HKogz hrafx1TXPJAtqVzo93VQXHYdJxzBB4EezWIPnZiqBUSf6Q69dX4LblKIAx+HCk+W1iNd A26wICxKNjWHrg1mCi0ysU8PcckLdVrymSpIU1vsW/QY/RvolBgxcKO7rySNToH6sKyj +c17EFjf/4m+U7vLmHsB1rHMAf3rEC9ayC4x4yODxOtcHD6QpVCIIzr8lXe7IJKir40c np2902ijXqJQk+NHuyOeNVUoW49e52KRWw5hYA9sbiS2/qSc2JvTmyqlan1ZEZmn3KgL cAnA== X-Gm-Message-State: AHPjjUhT5MPPxEwIXVatFRavGkruDUNrIpJSnF7CNgKlkiyVd8zlbhzq f+poA9CF+T3xoKRMXKc= X-Google-Smtp-Source: AOwi7QCVeP+rRpGq0GKVi9wyy9Yu/Qd+bIhaim8UcONPwn0m/NdEYZfrlynSO2CHHdQ7Kq3LyIO01Q== X-Received: by 10.25.207.13 with SMTP id f13mr6421816lfg.151.1505259623272; Tue, 12 Sep 2017 16:40:23 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id 15sm2702288ljf.22.2017.09.12.16.40.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 16:40:22 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> <838thlthx9.fsf@gnu.org> From: Dmitry Gutov Message-ID: <0464c886-bd32-7252-7820-50e00e7fa0c7@yandex.ru> Date: Wed, 13 Sep 2017 02:40:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <838thlthx9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/11/17 5:43 PM, Eli Zaretskii wrote: >>>> that would require support from backends, then. >> >> To make "fuzzy" work. > > It would be good to have other back-ends support that, but I don't > think it's a must. First, no one said all the back-ends must > distinguish between the two modes; it could even be that only one > makes sense for some language. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.44 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.44 listed in wl.mailspike.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.44 listed in dnsbl.sorbs.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/11/17 5:43 PM, Eli Zaretskii wrote: >>>> that would require support from backends, then. >> >> To make "fuzzy" work. > > It would be good to have other back-ends support that, but I don't > think it's a must. First, no one said all the back-ends must > distinguish between the two modes; it could even be that only one > makes sense for some language. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.44 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.44 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.44 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/11/17 5:43 PM, Eli Zaretskii wrote: >>>> that would require support from backends, then. >> >> To make "fuzzy" work. > > It would be good to have other back-ends support that, but I don't > think it's a must. First, no one said all the back-ends must > distinguish between the two modes; it could even be that only one > makes sense for some language. How will we define that it "makes sense"? There are two ways it could work: - Like etags, try to match all words on the same line as the legitimate definitions. For most backends, this will simply be impossible (for those that use a concise index instead of a flat list of strings). E.g., the elisp backend can't implement that. - Allow substring matching for definition names? But xref-find-apropos already lets you do that. > And second, I'm guess that this new > method will only be useful to those who are accustomed to etags. > > So I think we could add this with only the etags back-end support for > now, and extend it later to other back-ends if needed. Should it be a defcustom in etags.el, then? That's not far from what I suggested in the first place. I hesitate to add a defcustom to xref.el that will only affect etags. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Sep 2017 15:33: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: To: Dmitry Gutov Cc: wbe@psr.com, 28403@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.1505316767612 (code B ref 28403); Wed, 13 Sep 2017 15:33:02 +0000 Received: (at 28403) by debbugs.gnu.org; 13 Sep 2017 15:32:47 +0000 Received: from localhost ([127.0.0.1]:38510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ds9eh-00009o-5V for submit@debbugs.gnu.org; Wed, 13 Sep 2017 11:32:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ds9ef-00009a-Ga for 28403@debbugs.gnu.org; Wed, 13 Sep 2017 11:32:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ds9eW-0005L3-9y for 28403@debbugs.gnu.org; Wed, 13 Sep 2017 11:32:40 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ds9eW-0005Kt-7V; Wed, 13 Sep 2017 11:32:36 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3612 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ds9eU-0004Ym-EH; Wed, 13 Sep 2017 11:32:36 -0400 Date: Wed, 13 Sep 2017 18:32:24 +0300 Message-Id: <83poauobqv.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <0464c886-bd32-7252-7820-50e00e7fa0c7@yandex.ru> (message from Dmitry Gutov on Wed, 13 Sep 2017 02:40:21 +0300) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> <838thlthx9.fsf@gnu.org> <0464c886-bd32-7252-7820-50e00e7fa0c7@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: wbe@psr.com, 28403@debbugs.gnu.org > From: Dmitry Gutov > Date: Wed, 13 Sep 2017 02:40:21 +0300 > > > It would be good to have other back-ends support that, but I don't > > think it's a must. First, no one said all the back-ends must > > distinguish between the two modes; it could even be that only one > > makes sense for some language. > > How will we define that it "makes sense"? I thought it would be self-evident, but maybe I was wrong. > > So I think we could add this with only the etags back-end support for > > now, and extend it later to other back-ends if needed. > > Should it be a defcustom in etags.el, then? That's not far from what I > suggested in the first place. That'd be okay, if the UI will be more friendly than letting the user concoct a list of function symbols. Thanks. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Sep 2017 12:14:01 +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: To: Eli Zaretskii Cc: wbe@psr.com, 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150539122325684 (code B ref 28403); Thu, 14 Sep 2017 12:14:01 +0000 Received: (at 28403) by debbugs.gnu.org; 14 Sep 2017 12:13:43 +0000 Received: from localhost ([127.0.0.1]:39861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsT1b-0006gC-BM for submit@debbugs.gnu.org; Thu, 14 Sep 2017 08:13:43 -0400 Received: from mail-lf0-f50.google.com ([209.85.215.50]:46653) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsT1a-0006g0-3p for 28403@debbugs.gnu.org; Thu, 14 Sep 2017 08:13:42 -0400 Received: by mail-lf0-f50.google.com with SMTP id m199so7516721lfe.3 for <28403@debbugs.gnu.org>; Thu, 14 Sep 2017 05:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DKInwvtjjZgCAqZVkfZ0UlChGDYkXZb/HQd/Eb51B48=; b=OxyBnAyq4U2furYfnZY7HIivkhbJCyJz4oKg55F5+gCSDoxGFaoLHn9/XhDq70qh5A 5Sy99QBQzfOt5+SKrVaVm6JCphKsgfY116LTcvJXwaSK8Wc4qxohEDP0fvqV801wFtzJ 3+Pkp/WXxIUjfX5mJWVLuD5/EXol6jF62WZvO/yVQkdB7pOimOyN/GMKidAPrE1sywrx nDQ/naiJvPMswymG8Ur0UhAcxWskKOGV55oX3U8aKqj+2ONRA9itXKsYNSxIsAc2Cfjm M2T2WrOyEcwCfhKXNlJ+wWHMu3cnOhCLIqJ1wAzlLQXK3c+hDEYYPCA32IGyTnF5jVnH VMfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DKInwvtjjZgCAqZVkfZ0UlChGDYkXZb/HQd/Eb51B48=; b=e5AkjCwHesyzn/u0liw796qMUt7d495J6v+daHD32azwGwW+k/ZkHlrM0veWToeE+2 /iYWzK2//NAa862ZHlksK5fxwbd/KC08CV6Mem2x+O278edzTuS4T95XkZM6w+7IBACa zLHRJrfYuemMH4EAT/x7ML2Vt/bFkbkjMD/FoOj37zkI73OzF8pmxFBCyeWSwOpcJgdL aFIVJTmpqsNTYqkbLTgjRhg4ZL9SHA9Tazhje9egNtyD0vtg5awpeYat0ytBc7DrJaso 7WFGwe+xGe9ji90aEP0TWN8/804/J6c0N295vUx9+vpq543YrgXdcaLR8uC2hofMOh7+ GqUw== X-Gm-Message-State: AHPjjUh0teTKFO4cfge7OwSi5FMCTmXnRvLdloz6LsGTpy73cgFDjssT s8mBv+goSPa3rinshQI= X-Google-Smtp-Source: AOwi7QBBrcIryNUfJ+WAl4tEEsUov2JAMsL+Z41h0Py0RSZdwEC9enb57/VuBh7fIvUVjkv1UqMEKg== X-Received: by 10.46.92.3 with SMTP id q3mr9173862ljb.41.1505391215927; Thu, 14 Sep 2017 05:13:35 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id g41sm2833872ljg.94.2017.09.14.05.13.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2017 05:13:35 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> <838thlthx9.fsf@gnu.org> <0464c886-bd32-7252-7820-50e00e7fa0c7@yandex.ru> <83poauobqv.fsf@gnu.org> From: Dmitry Gutov Message-ID: <48b2816b-6fa5-bb3e-14e3-fff85d4fbc14@yandex.ru> Date: Thu, 14 Sep 2017 15:13:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <83poauobqv.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/13/17 6:32 PM, Eli Zaretskii wrote: >> Should it be a defcustom in etags.el, then? That's not far from what I >> suggested in the first place. > > That'd be okay, if the UI will be more friendly than letting the user > concoct a list of function symbols. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.50 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.50 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.50 listed in list.dnswl.org] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/13/17 6:32 PM, Eli Zaretskii wrote: >> Should it be a defcustom in etags.el, then? That's not far from what I >> suggested in the first place. > > That'd be okay, if the UI will be more friendly than letting the user > concoct a list of function symbols. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.50 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.50 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.50 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/13/17 6:32 PM, Eli Zaretskii wrote: >> Should it be a defcustom in etags.el, then? That's not far from what I >> suggested in the first place. > > That'd be okay, if the UI will be more friendly than letting the user > concoct a list of function symbols. I'd approve probably any patch that makes etags-xref-find-definitions-tag-order into a defcustom, or even creates a new option governing it. But maybe it's not necessary after all? I think we've addressed Winston's needs in different ways by now. Maybe the manual should advertise the necessity to call etags with --regexp in certain cases more prominently instead. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Sep 2017 17:14:01 +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: To: Dmitry Gutov Cc: wbe@psr.com, 28403@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15054092213198 (code B ref 28403); Thu, 14 Sep 2017 17:14:01 +0000 Received: (at 28403) by debbugs.gnu.org; 14 Sep 2017 17:13:41 +0000 Received: from localhost ([127.0.0.1]:41338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsXht-0000pV-4M for submit@debbugs.gnu.org; Thu, 14 Sep 2017 13:13:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsXhr-0000pH-A1 for 28403@debbugs.gnu.org; Thu, 14 Sep 2017 13:13:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dsXhi-0005h3-Rr for 28403@debbugs.gnu.org; Thu, 14 Sep 2017 13:13:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dsXhi-0005gx-OO; Thu, 14 Sep 2017 13:13:30 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1281 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dsXhh-0007Fa-Rk; Thu, 14 Sep 2017 13:13:30 -0400 Date: Thu, 14 Sep 2017 20:13:31 +0300 Message-Id: <83zi9xmcec.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <48b2816b-6fa5-bb3e-14e3-fff85d4fbc14@yandex.ru> (message from Dmitry Gutov on Thu, 14 Sep 2017 15:13:33 +0300) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> <838thlthx9.fsf@gnu.org> <0464c886-bd32-7252-7820-50e00e7fa0c7@yandex.ru> <83poauobqv.fsf@gnu.org> <48b2816b-6fa5-bb3e-14e3-fff85d4fbc14@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: wbe@psr.com, 28403@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 Sep 2017 15:13:33 +0300 > > On 9/13/17 6:32 PM, Eli Zaretskii wrote: > > >> Should it be a defcustom in etags.el, then? That's not far from what I > >> suggested in the first place. > > > > That'd be okay, if the UI will be more friendly than letting the user > > concoct a list of function symbols. > > I'd approve probably any patch that makes > etags-xref-find-definitions-tag-order into a defcustom, or even creates > a new option governing it. > > But maybe it's not necessary after all? I think we've addressed > Winston's needs in different ways by now. I just feel that having a user-friendly defcustom would be more future-proof. Like I said: it's a fire escape. Every complex feature needs one. > Maybe the manual should advertise the necessity to call etags with > --regexp in certain cases more prominently instead. Until very recently, --regex didn't even document the back-substitution feature it provides. So we still have a way to go in that direction. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions References: <201709092240.v89MeFUo014854@psr.com> In-Reply-To: <201709092240.v89MeFUo014854@psr.com> Resent-From: Winston Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Sep 2017 17:38:01 +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: To: Eli Zaretskii , Dmitry Gutov Cc: 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15054106305402 (code B ref 28403); Thu, 14 Sep 2017 17:38:01 +0000 Received: (at 28403) by debbugs.gnu.org; 14 Sep 2017 17:37:10 +0000 Received: from localhost ([127.0.0.1]:41372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsY4c-0001P2-AF for submit@debbugs.gnu.org; Thu, 14 Sep 2017 13:37:10 -0400 Received: from mail.psr.com ([67.212.42.216]:24537 helo=psr.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsY4Y-0001OY-LT for 28403@debbugs.gnu.org; Thu, 14 Sep 2017 13:37:08 -0400 Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.15.2/8.15.2) with ESMTPS id v8EHb6Gv038579 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Sep 2017 13:37:06 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.15.2/8.15.2/Submit) id v8EHb6Ao038578; Thu, 14 Sep 2017 13:37:06 -0400 (EDT) (envelope-from wbe) Message-Id: <201709141737.v8EHb6Ao038578@psr.com> Date: Thu, 14 Sep 2017 13:37 EDT From: Winston X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Dmitry suggested: > Maybe the manual should advertise the necessity to call etags with > --regexp in certain cases more prominently instead. On the assumption that no one will read the manual until they have to, I'd still suggest at least a 1-sentence mention of the issue in the documentation for xref-find-definitions, even if it mostly says see the manual if you're having problems finding tags. -WBE From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Sep 2017 22:09: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: To: Winston , Eli Zaretskii Cc: 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15054268944863 (code B ref 28403); Thu, 14 Sep 2017 22:09:02 +0000 Received: (at 28403) by debbugs.gnu.org; 14 Sep 2017 22:08:14 +0000 Received: from localhost ([127.0.0.1]:41608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dscIv-0001GN-RT for submit@debbugs.gnu.org; Thu, 14 Sep 2017 18:08:14 -0400 Received: from mail-lf0-f48.google.com ([209.85.215.48]:56628) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dscIu-0001GB-0h for 28403@debbugs.gnu.org; Thu, 14 Sep 2017 18:08:12 -0400 Received: by mail-lf0-f48.google.com with SMTP id a18so675952lfl.13 for <28403@debbugs.gnu.org>; Thu, 14 Sep 2017 15:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GzqusFq+544QnyLwJ/3jlk8TO9CoSBorKU4QcvpdRYE=; b=EPBZqIRET+SGaEVGEcJrZZnScY/umCXWVLwQNpSMOxCInowg9oG6ucgUJINqKGyLKY eOKeRkNBeLR4WYQILJybRDNzkIY5IEDtg0eB41TQ2gfcgBseMFq6PmZeux9/r7dcr83p hp7yuMUTeEAOWdIKSBLehNM3GtnVgyIcuvcIyV/TPhlci4iPZWnINGqaFnO4kdQCTt+i punZPbl9wV5NqQRvwPHoUhIpuRBdHILdWjyqFXXUz5gVLIDmabU694NTGIqJ0a5vvE5v XlM8x87k5vesbSucjXMqTh9gQA7NKcr9E8Inna/xizFBTM8FqBXTvCw3j+7LdB3nrYvN EikA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GzqusFq+544QnyLwJ/3jlk8TO9CoSBorKU4QcvpdRYE=; b=jBVkrsK0C+N4QL1G/xNAoj5ojMYwlRWTfHPt1RCPHf1uXfMVkCggInvVYNC3pz4q0D hf9CKb7HI/YaPV+WszmB4/wjAeeHHRinWTuXOfgA9xFZbxrx9Q0djMz3+jzqnPENe1D6 fQBvvJeLyhNHpSu3IQ+b3ODurl0CONjLbqsuaonVq3w8S056ZPlm8syEHyRtGWXPDJqk bo7tH7k6sCasiGd0FZC6BHm/oCNbSCBavRFyIaphNp22xxSJaHSPkx2UW1cQS4e6LgLD PURuBnHZxh9sOV4rZTF3dbJVCyQysPdDw/Z5eteGOZzH48D8H72ccakqlR+NGz0on0yk mPjQ== X-Gm-Message-State: AHPjjUiZSDfLVojOX+TunGngWTsOifP4FT4Eio5WrKj/pSWBChqF+NfP S4LYheFEHwUF5Xhpf2k= X-Google-Smtp-Source: AOwi7QD5TUFrOM+1OJBRF3JzEIgDIRO95f6O4gl6AcOLYONlBAL66iobkjDIUYMm2H34FJMa6oKVgw== X-Received: by 10.25.18.71 with SMTP id h68mr8664953lfi.217.1505426886104; Thu, 14 Sep 2017 15:08:06 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id f199sm3157984lfg.85.2017.09.14.15.08.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2017 15:08:04 -0700 (PDT) References: <201709141737.v8EHb6Ao038578@psr.com> From: Dmitry Gutov Message-ID: <97f250ef-a63e-4552-0b6d-bbeadabaa475@yandex.ru> Date: Fri, 15 Sep 2017 01:08:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <201709141737.v8EHb6Ao038578@psr.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/14/17 8:36 PM, Winston wrote: > Dmitry suggested: >> Maybe the manual should advertise the necessity to call etags with >> --regexp in certain cases more prominently instead. > > On the assumption that no one will read the manual until they have to, > I'd still suggest at least a 1-sentence mention of the issue in the > documentation for xref-find-definitions, even if it mostly says see the > manual if you're having problems finding tags. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.48 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.48 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.48 listed in wl.mailspike.net] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/14/17 8:36 PM, Winston wrote: > Dmitry suggested: >> Maybe the manual should advertise the necessity to call etags with >> --regexp in certain cases more prominently instead. > > On the assumption that no one will read the manual until they have to, > I'd still suggest at least a 1-sentence mention of the issue in the > documentation for xref-find-definitions, even if it mostly says see the > manual if you're having problems finding tags. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.48 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.48 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.48 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/14/17 8:36 PM, Winston wrote: > Dmitry suggested: >> Maybe the manual should advertise the necessity to call etags with >> --regexp in certain cases more prominently instead. > > On the assumption that no one will read the manual until they have to, > I'd still suggest at least a 1-sentence mention of the issue in the > documentation for xref-find-definitions, even if it mostly says see the > manual if you're having problems finding tags. Yes, well, I probably agree from the standpoint of practicality. Even though xref-find-definitions itself knows zilch about etags. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Sep 2017 00:45: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: To: Eli Zaretskii Cc: wbe@psr.com, 28403@debbugs.gnu.org Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.15057818806383 (code B ref 28403); Tue, 19 Sep 2017 00:45:02 +0000 Received: (at 28403) by debbugs.gnu.org; 19 Sep 2017 00:44:40 +0000 Received: from localhost ([127.0.0.1]:47015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1du6eV-0001et-SV for submit@debbugs.gnu.org; Mon, 18 Sep 2017 20:44:40 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:33860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1du6eT-0001ef-Dh for 28403@debbugs.gnu.org; Mon, 18 Sep 2017 20:44:37 -0400 Received: by mail-lf0-f67.google.com with SMTP id h80so1125326lfe.1 for <28403@debbugs.gnu.org>; Mon, 18 Sep 2017 17:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=duMKBYJYQlCerqUelQuaX75RNJa4zTHAOjvv8+eX6Zw=; b=MYR1RYiOBrgxGYb/X/vH+YegOoBBGHEdxQpwnyg1CtS3QvWU0sfdvdsbo6XDsr0lOq EekBiBVwFRcl4SfRgv9MwilGjvbmwHqcU/+SAP+AEKbYQVhWpZSvnz4g3ZOCf6HH2N/3 DKbTPlldvV9/ThhJQaF9wMfSFKnfrHbfaELtvBQ1BD8ZqQso/V42CpXjpOnzx+RcO91O X9QXNsgBUriidosfJMMdD7kVcwr2djWYYn/sOEqjfbwIjrCQOHQ6LgHyMjM4oNsKg0/4 BroNjlrJcN4HaLlRFnjWbjK/Qouy5wZox9DTTDu0bUnKvKdpjLil2ajSIJ1AxD8MYq4I OTLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=duMKBYJYQlCerqUelQuaX75RNJa4zTHAOjvv8+eX6Zw=; b=VeSfmzqCvrQU16eYYmmt18HhIYmJF6tuztDjBtQaqR5Yn4j34MrRUEHy9h2FAoxmzp jKoD9V1Al+BvvWec3RqTj9/Mez0T9qgLLLfCHsNPWSyLX3kxLSWXDUALOkH9DFT7sTpU d1xHsU+2vFv4NkQzBJ4N4TmjVvvy31SQPLgspDLdFd4cdrfeB+o1FsObz64+3CCBrl8s 9MiIjvG9pFdRbllDv6FP/Rwh2ktOcYdMm4UQVS+2E3RMRHdkOavTfD6d0M29UNrl0TK3 xMQUtEuzXd6jqieXNzktOvRaZBUDSg4GEwr1hECVthplFB3mReZqVwWVU1Bk6evPp8cK vJGg== X-Gm-Message-State: AHPjjUgK8ul8gXdpwYJnzQ7hP203iSAK7SGVPDCw9X8D/XXpLbLKO9D8 RWhupA4PzLWhbFi04u4= X-Google-Smtp-Source: AOwi7QDHtBFgf9wO9GPzBZmdSyU0/5bkUST85xVehzAhqrx0NEIAGGg8J+I1xUwZ0rIVDLmjC0/RZw== X-Received: by 10.46.91.144 with SMTP id m16mr10328378lje.95.1505781871343; Mon, 18 Sep 2017 17:44:31 -0700 (PDT) Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id c185sm1613099lfd.67.2017.09.18.17.44.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 17:44:29 -0700 (PDT) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> <838thlthx9.fsf@gnu.org> <0464c886-bd32-7252-7820-50e00e7fa0c7@yandex.ru> <83poauobqv.fsf@gnu.org> <48b2816b-6fa5-bb3e-14e3-fff85d4fbc14@yandex.ru> <83zi9xmcec.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Tue, 19 Sep 2017 03:44:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: <83zi9xmcec.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/14/17 8:13 PM, Eli Zaretskii wrote: > I just feel that having a user-friendly defcustom would be more > future-proof. Like I said: it's a fire escape. Every complex feature > needs one. My point is if we document it enough for the majority of the users to find it, it would also make it more likely that they go the fire escape route instead of using etags in the right way. And then get some other wrong impression about xref-find-definitions. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.67 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.67 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.67 listed in wl.mailspike.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/14/17 8:13 PM, Eli Zaretskii wrote: > I just feel that having a user-friendly defcustom would be more > future-proof. Like I said: it's a fire escape. Every complex feature > needs one. My point is if we document it enough for the majority of the users to find it, it would also make it more likely that they go the fire escape route instead of using etags in the right way. And then get some other wrong impression about xref-find-definitions. [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [209.85.215.67 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.67 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.215.67 listed in list.dnswl.org] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 9/14/17 8:13 PM, Eli Zaretskii wrote: > I just feel that having a user-friendly defcustom would be more > future-proof. Like I said: it's a fire escape. Every complex feature > needs one. My point is if we document it enough for the majority of the users to find it, it would also make it more likely that they go the fire escape route instead of using etags in the right way. And then get some other wrong impression about xref-find-definitions. >> Maybe the manual should advertise the necessity to call etags with >> --regexp in certain cases more prominently instead. > > Until very recently, --regex didn't even document the > back-substitution feature it provides. So we still have a way to go > in that direction. No argument from me. From unknown Wed Jun 25 10:53:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28403: 25.2; find-tag works, but xref-find-definitions Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Sep 2017 03:59: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: To: Dmitry Gutov Cc: wbe@psr.com, 28403@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 28403-submit@debbugs.gnu.org id=B28403.150579351431502 (code B ref 28403); Tue, 19 Sep 2017 03:59:02 +0000 Received: (at 28403) by debbugs.gnu.org; 19 Sep 2017 03:58:34 +0000 Received: from localhost ([127.0.0.1]:47113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1du9gA-0008C2-6G for submit@debbugs.gnu.org; Mon, 18 Sep 2017 23:58:34 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1du9g8-0008Bn-1L for 28403@debbugs.gnu.org; Mon, 18 Sep 2017 23:58:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1du9fy-0004Hh-Qr for 28403@debbugs.gnu.org; Mon, 18 Sep 2017 23:58:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1du9fy-0004HZ-NK; Mon, 18 Sep 2017 23:58:22 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1234 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1du9fx-0005U5-R9; Mon, 18 Sep 2017 23:58:22 -0400 Date: Tue, 19 Sep 2017 06:58:10 +0300 Message-Id: <83wp4vgx0t.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Dmitry Gutov on Tue, 19 Sep 2017 03:44:28 +0300) References: <201709092240.v89MeFUo014854@psr.com> <201709100250.v8A2o6nL015568@psr.com> <837ex6vd83.fsf@gnu.org> <83k216t0wp.fsf@gnu.org> <835dc374-4846-0cb6-9fd6-ddef93711a37@yandex.ru> <838thlthx9.fsf@gnu.org> <0464c886-bd32-7252-7820-50e00e7fa0c7@yandex.ru> <83poauobqv.fsf@gnu.org> <48b2816b-6fa5-bb3e-14e3-fff85d4fbc14@yandex.ru> <83zi9xmcec.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: wbe@psr.com, 28403@debbugs.gnu.org > From: Dmitry Gutov > Date: Tue, 19 Sep 2017 03:44:28 +0300 > > On 9/14/17 8:13 PM, Eli Zaretskii wrote: > > > I just feel that having a user-friendly defcustom would be more > > future-proof. Like I said: it's a fire escape. Every complex feature > > needs one. > > My point is if we document it enough for the majority of the users to > find it, it would also make it more likely that they go the fire escape > route instead of using etags in the right way. And then get some other > wrong impression about xref-find-definitions. Fire escapes don't have to be documented, just pointed out when and if someone really needs them.