From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions Date: Tue, 30 Dec 2014 22:43:55 +0200 Message-ID: <54A30E8B.1020207@yandex.ru> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1419972261 16772 80.91.229.3 (30 Dec 2014 20:44:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2014 20:44:21 +0000 (UTC) Cc: 19466@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 30 21:44:14 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 1Y63eH-0001CQ-5X for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 21:44:13 +0100 Original-Received: from localhost ([::1]:38237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y63eG-0000XC-EW for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 15:44:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y63eC-0000Sw-NP for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 15:44:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y63e6-0003z6-Uq for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 15:44:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y63e6-0003yd-Qb for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 15:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y63e6-0001rU-GH for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 15:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 20:44:02 +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.14199722407141 (code B ref 19466); Tue, 30 Dec 2014 20:44:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 30 Dec 2014 20:44:00 +0000 Original-Received: from localhost ([127.0.0.1]:33177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y63e4-0001r7-Av for submit@debbugs.gnu.org; Tue, 30 Dec 2014 15:44:00 -0500 Original-Received: from mail-wg0-f54.google.com ([74.125.82.54]:54479) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y63e1-0001qw-Th for 19466@debbugs.gnu.org; Tue, 30 Dec 2014 15:43:58 -0500 Original-Received: by mail-wg0-f54.google.com with SMTP id z12so3377139wgg.13 for <19466@debbugs.gnu.org>; Tue, 30 Dec 2014 12:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oDZXE8zq3IpGi+SV8zdyMAk5JYv4pE7w2h/AtfngTls=; b=hb/WywsEk3ltbmzm3d6gya0UyiJ/VcUVNyFQyp4vWJ6BQrxvEOfDrR8jsr7+xT9RkI ZeiQnod/GjjVuaBLDyS/JT2g5TlzJS0GGrk8RcSv+B0mjDvX0jWrzPM1a6vdfGD+jx11 3cyMwDmdbEnwyRWkUT2AZ2BBhLPVKkFNGaVzrXGw8WOZ0rLvOpyeYQs0zHz+Ujj9DAB6 SbYjUojl9XlqT51PE7okgLuXS1C9VjVvUO0WkNGsOl9vIEKYun/y7quUvfeA3xwOvFPs +GwAFi9zaczIVEycIJyAHQJIysKFYDxg1UYACZa6lFtPB1tBoRhAJCwU6PJbjVg2Tidu xw8w== X-Received: by 10.180.210.195 with SMTP id mw3mr106911657wic.79.1419972237330; Tue, 30 Dec 2014 12:43:57 -0800 (PST) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id r3sm44682785wic.10.2014.12.30.12.43.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 12:43:56 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <83vbktb1ct.fsf@gnu.org> 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:97882 Archived-At: On 12/30/2014 05:31 PM, Eli Zaretskii wrote: > 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. I wouldn't say it is (lisp-interaction-mode inherits from emacs-lisp-mode). And if we consider the scratch vs any .el file in the Emacs sources, it's less natural to use tags in scratch because it's conceptually farther from emacs/src/TAGS. >> 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? Sure, but that has to be written in a sensible manner, too. Emacs core still has no notion of projects (or even moreso, project types), so it's harder to say "also use etags when in the Emacs sources". Not all projects use etags, and this is almost never true in third-party Lisp projects, such as ELPA packages. > 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. So if you're fine with tags, do you at all need the specialized navigation provided by emacs-lisp-mode? Like suggested, you could undo the changes made by emacs-lisp-mode to xref-* variables in emacs-lisp-mode-hook. A couple of `kill-local-variable' would suffice. But personally, I'd never choose tags over find-func, and it's not a good default for the many users and third-party developers out there. > 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. Let's hope so.