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: Fri, 02 Jan 2015 19:52:54 +0200 Message-ID: <54A6DAF6.5070605@yandex.ru> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.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 1420221260 6682 80.91.229.3 (2 Jan 2015 17:54:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Jan 2015 17:54:20 +0000 (UTC) Cc: 19466@debbugs.gnu.org To: Stefan Monnier , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 02 18:54:13 2015 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 1Y76QO-000647-C3 for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jan 2015 18:54:12 +0100 Original-Received: from localhost ([::1]:52176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y76QN-0003tr-GE for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jan 2015 12:54:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y76QJ-0003sF-Tt for bug-gnu-emacs@gnu.org; Fri, 02 Jan 2015 12:54:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y76QE-0000pe-U6 for bug-gnu-emacs@gnu.org; Fri, 02 Jan 2015 12:54:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y76QE-0000pY-RI for bug-gnu-emacs@gnu.org; Fri, 02 Jan 2015 12:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y76QE-0002Uv-4h for bug-gnu-emacs@gnu.org; Fri, 02 Jan 2015 12:54: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: Fri, 02 Jan 2015 17:54: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.14202211849525 (code B ref 19466); Fri, 02 Jan 2015 17:54:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 2 Jan 2015 17:53:04 +0000 Original-Received: from localhost ([127.0.0.1]:35271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y76PH-0002TY-8j for submit@debbugs.gnu.org; Fri, 02 Jan 2015 12:53:03 -0500 Original-Received: from mail-wi0-f169.google.com ([209.85.212.169]:55351) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y76PE-0002T7-6h for 19466@debbugs.gnu.org; Fri, 02 Jan 2015 12:53:00 -0500 Original-Received: by mail-wi0-f169.google.com with SMTP id r20so930186wiv.0 for <19466@debbugs.gnu.org>; Fri, 02 Jan 2015 09:52:59 -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=G9D03l2z/DU1ah5vCEeyXdJFt6IbEzq9r7f65vUfGog=; b=QWk7aP7Il56J0/4imi6g9XZEBO28NOKyfOPOhQzNpxZ01PfePvwRNm8RkZr0y3fAQw OwgL0P/Cl5vMK9HS76EmL9lZGP3bEJpTX7wcP5C5LN0uPi1PFmBw5zN9CHSgOLWLZFtA N0L0KWIhSEjJcumGdkmBBQnaiDZc4pyImWnPNr0NJZmVkVgcdZKgMBQ0lfpFWYnoHudC yITwLIDWgpjNmw9w8BLbNpEpHapfKUAc2cgGADiZP2yS2pw3HpE+nHOnbsaC46aZTrWA 0JAa0taQZIIbWoGgEU6Q/e+LeM0uN5bZIq76Vk8RjzJcgETq3BcldZBsXhWGAa6F3jJR cAxQ== X-Received: by 10.181.29.198 with SMTP id jy6mr7550557wid.0.1420221179525; Fri, 02 Jan 2015 09:52:59 -0800 (PST) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id et4sm65360866wjd.15.2015.01.02.09.52.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jan 2015 09:52:58 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: 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:97945 Archived-At: On 12/31/2014 12:44 AM, Stefan Monnier wrote: > I think it's not just a matter of combining several major modes: you > need to know where the various files are and how they relate. IOW there > needs to be some other logic on top of it and different systems will > require different such logic. Or, to put it another way: if someone is editing ELPA code in its own repo and presses `C-u M-.', I'm not sure it's reasonable to include all C functions and macros in the list of suggested identifiers. After all, they are writing Elisp, not C. One way to deal with this would be to add a minor mode, one that people could enable on by-file or by-project basis (say, in Emacs's .dir-locals.el). This xref-emacs-sources-mode would merge identifiers from both the Elisp and Etags backends, and try to merge the search results for different search actions as well. It will return duplicate results, though. And filtering them out will be non-trivial. For instance, if find-func and src/TAGS are merge, jumping to `car' would yield one xref-elisp-location, and one xref-file-location. How do you compare them, if one has fields with values "car" and "src/data.c", and the other "DEFUN ("car", Fcar," and "/full/p/t/emacs/src/data.c"? Do we really want to include lisp/TAGS? It has both pros and cons. Pros: we can jump to all functions, even non-autoloaded ones in all packages. Cons: we do see all the functions, even ones we don't care about (their packages aren't loaded). Based on my positive experience with find-func, maybe 98% of the time the user won't really need them. And duplicates, a lot more than with src/TAGS. So someone should really consider if we ever need find-func and lisp/TAGS used together. Because if Eli only wants to use tag files when working on Emacs, the respective minor mode looks a lot simpler: (defvar xref-etags-mode--save nil) (define-minor-mode xref-etags-mode "Toggle using only the tag files for navigation." :lighter "" (if xref-etags-mode (progn (setq xref-etags-mode--save (cons xref-find-function xref-identifier-completion-table-function)) (kill-local-variable 'xref-find-function) (kill-local-variable 'xref-identifier-completion-table-function)) (setq-local xref-find-function (car xref-etags-mode--save)) (setq-local xref-identifier-completion-table-function (cdr xref-etags-mode--save)))) Add it to find-file-hook, maybe predicated on buffer-file-name.