From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions Date: Tue, 30 Dec 2014 17:31:46 +0200 Message-ID: <83vbktb1ct.fsf@gnu.org> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1419953599 19986 80.91.229.3 (30 Dec 2014 15:33:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2014 15:33:19 +0000 (UTC) Cc: 19466@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 30 16:33:11 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y5ynG-0001ve-Ad for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 16:33:10 +0100 Original-Received: from localhost ([::1]:37248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5ynF-0006NS-Lp for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 10:33:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5ynB-0006NN-Ov for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:33:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5yn8-0001k6-Jy for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:33:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5yn8-0001k2-Gy for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y5yn8-0000Bm-13 for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 10:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 15:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19466 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19466-submit@debbugs.gnu.org id=B19466.1419953521601 (code B ref 19466); Tue, 30 Dec 2014 15:33:01 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 15:32:01 +0000 Original-Received: from localhost ([127.0.0.1]:32941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5ym8-00009Z-Rt for submit@debbugs.gnu.org; Tue, 30 Dec 2014 10:32:01 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:54851) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5ym6-00009O-0q for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 10:31:59 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NHE00J00J0O2200@mtaout28.012.net.il> for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 17:29:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHE008G4J1N4WA0@mtaout28.012.net.il>; Tue, 30 Dec 2014 17:29:47 +0200 (IST) In-reply-to: <54A230CD.3040309@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:97834 Archived-At: > Date: Tue, 30 Dec 2014 06:57:49 +0200 > From: Dmitry Gutov > > On 12/29/2014 09:27 PM, Eli Zaretskii wrote: > > Run "make TAGS" in the top-level directory, then: > > emacs -Q > Click menu-bar->Edit->Go To->Set Tags File Name > Navigate to src/TAGS and select it in the file selection dialog > Click menu-bar->Edit->Go To->Find Definition > Type "display_line RET" at the prompt > => [No match] > > Are you doing that in e.g. emacs-lisp-mode buffer? I did it in *scratch*. But *scratch*'s major mode is not emacs-lisp-mode, it's lisp-interaction-mode. I think the difference is significant for the purposes of this discussion. > Naturally, it wouldn't work, because that major mode defines its own identifier completion table and find-definition function. > > I understand what you're trying to do, but don't see a way to achieve that while keeping the uniform interface for the user in different major modes (which can use different navigation logic). Isn't it possible to _prefer_ the symbols that are consistent with the major mode, but not entirely discard the other possible candidates? In a mixed-language project such as Emacs, these subtle conditions that completely conceal symbols depending on the current mode, make very little sense to me. (And there are other mixed-language projects out there, like Guile, GDB, etc.) The Emacs TAGS tables traditionally included tags from lisp/ files in src/TAGS, and for a very good reason. > Suggestions welcome, but maybe you should just keep using `find-tag'. The generic navigation commands are more useful to have as the menu items, though. I assume that this new facility is an improvement, so I _want_ to use it. Especially since NEWS says: ** etags As a result of the above, these commands are now obsolete: `find-tag-other-window', `find-tag-other-frame', `find-tag-regexp', `tags-apropos' and `tags-loop-continue'. Considering something obsolete means that a replacement is available that is as good or better than the replaced feature. I don't want to go back to obsolete commands, unless I really have to, i.e. unless I find the situation with xref unbearable. I hope we are not there yet. > Alternatively, you could reset `xref-find-function' and `xref-identifier-completion-table-function' to their default values in `emacs-lisp-mode-hook'. That could be a decent choice if your TAGS file includes the lisp files as well. See above: out src/TAGS includes lisp/TAGS. We do this for a long time, and it's a tremendously useful thing when working on Emacs development.