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, 23 Jan 2015 19:34:45 +0200 Message-ID: <54C28635.8070606@yandex.ru> References: <8361cucl3u.fsf@gnu.org> <54A230CD.3040309@yandex.ru> <83vbktb1ct.fsf@gnu.org> <54A2EE15.3020406@yandex.ru> <831tnhasx0.fsf@gnu.org> <54A6DAF6.5070605@yandex.ru> <831tna9tmr.fsf@gnu.org> <54A9C94F.8040701@yandex.ru> <83vbkl99vm.fsf@gnu.org> <54B8878A.4050506@yandex.ru> <54B8C22B.3080200@gmx.at> <54BC7A77.5020307@yandex.ru> <54BCC033.2010104@gmx.at> <83oapuy8ew.fsf@gnu.org> <54BDC34C.5070309@yandex.ru> <83wq4hwejl.fsf@gnu.org> <54BEBF63.9050709@yandex.ru> <8361c0w16n.fsf@gnu.org> <54C063E3.8020401@yandex.ru> <83a91avglz.fsf@gnu.org> <54C1655E.4050403@yandex.ru> <83r3uluawd.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 1422034517 24074 80.91.229.3 (23 Jan 2015 17:35:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 17:35:17 +0000 (UTC) Cc: eller.helmut@gmail.com, 19466@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 18:35:16 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 1YEi8Z-0005Zs-4P for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 18:35:15 +0100 Original-Received: from localhost ([::1]:60641 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEi8Y-0008AK-GS for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 12:35:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEi8Q-00084u-LO for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 12:35:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEi8N-00023G-8F for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 12:35:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEi8N-00023A-3a for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 12:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YEi8L-0006nz-UP for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 12:35: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, 23 Jan 2015 17:35: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.142203449826146 (code B ref 19466); Fri, 23 Jan 2015 17:35:01 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 17:34:58 +0000 Original-Received: from localhost ([127.0.0.1]:54560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEi8G-0006nd-P7 for submit@debbugs.gnu.org; Fri, 23 Jan 2015 12:34:57 -0500 Original-Received: from mail-wi0-f182.google.com ([209.85.212.182]:38721) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEi8E-0006nO-1T for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 12:34:54 -0500 Original-Received: by mail-wi0-f182.google.com with SMTP id n3so4388476wiv.3 for <19466@debbugs.gnu.org>; Fri, 23 Jan 2015 09:34:47 -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=t7wOH8ODAF1hVdmIx7XjIP9HEM4zDC8hTQpW86y/eQo=; b=VFtgp6GzDRIlxHKp4YJF61ve+95RP9I4dXvAK57ZMxhsseV26KL2GZmWHyy4K0rrnh /Flu1yPr2vfvGpV6c5O7FvLJ+7wPiFEGSu9oFbh7LeD/aXakzlqbWqeYCq1KB/XHutOU ERDEm5HC1pD0eVPD3hGjSMnSAfzdnShaBd5csXXJB2Z9SFbH1sYRcl4Ey1vH0c8MXbrb weNTWflFeVDsxeJgd4i1BUvq7xXODKQ1Ue/6YEGHvkyQ2ZKP3YEH6nM1lmS4lGFojs6O R0EXmlx6idxLcgeyjAUWVwGW2UBBrubzwsciC6eJ6PagRGwmVP9MMaWzJ/xKc57EqWS6 nylA== X-Received: by 10.194.81.104 with SMTP id z8mr16145446wjx.45.1422034487731; Fri, 23 Jan 2015 09:34:47 -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 gm10sm2645630wib.19.2015.01.23.09.34.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 09:34:47 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <83r3uluawd.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:98643 Archived-At: On 01/23/2015 11:03 AM, Eli Zaretskii wrote: > Most, if not all, projects I work on aren't "projects" in your sense > of the word, I think -- they lack any "project" files except the > sources and Makefile's. A top Makefile is enough for me, conceptually. > With etags, I switch "projects" by invoking > visit-tags-table and typing a name of a different TAGS file (I'm then > given a choice of whether to keep the previous TAGS table or discard > it, which is important -- see below). I would consider this you adapting to Emacs's lack of support for projects: many people like to have commands that work on the "current project" (find-file, replace, etc), and depend on which buffer you're currently in. But anyway... > If xref can reliably deduce that I switched projects and automatically > update its database, that's fine with me, and would probably > constitute what you mean by "dependence on the current file or > project". There's no single database. If you're using the etags backend, it should be just as affected by `M-x visit-tags-table', as `find-tag' is. So that should be good enough. > Take, for example, the use case where I'm testing a program and found > a bug. I then need to be able to quickly find and examine the > definition of symbols that might be involved in the bug, look at their > code, perhaps make some changes -- this all will be served well by > using the database (such as TAGS) of that single program. But suppose > I now come to the conclusion that the bug is not in the program per > se, but involves one of the external libraries it uses. Now I need to > go through the sources of that library (whose sources, by sheer luck > or maybe something else, I already have available on my system). How > would xref or etags know whether I switched to that library as part of > my previous work (and therefore still need access to the previous > project's symbols), or because I'm now working on an entirely > different project? What if investigating the bug needs to > intermittently look at the sources of the program and the library > (e.g., because the bug happens due to some incompatibility between > them)? Honestly, I would probably run two instances of Emacs. But the tags-file-name/tags-table-list approach should still work, as long as the etags backend is used. Note that currently the only thing that depends on a specific buffer is the backend used. And the only buffers that use the non-default value now are in emacs-lisp-mode or its derivatives. Until that changes, applying either of the code samples I presented should give you find-tag-ish behavior everywhere. So I was a bit too alarmist about you having to use find-file-hook and different major mode hooks.... yet. > So I think there will always be a need for asking the user about this, > and in addition there are projects without "project" infrastructure, > where xref or etags or any similar feature will have to rely on the > user for telling them which database of symbols to use. A project infrastructure should take priority over this. For instance, how the current Projectile users switch to a file in a "different project"? They call `M-x projectile-switch-project', pick one from the cached list of projects, and then `M-x projectile-find-file' in the resulting buffer. I believe this kind of workflow scales better. The logic behind determining the current project is entirely configurable, so there's no reason why a directory with a Makefile can't be considered a project, if the user is so inclined. > Is xref ready for these use cases? If so, in what form (simple > variable customizations, specified commands, Lisp code that the use > must supply, something else) can the user specify what she wants? If they really want to, using simple functions and major mode hooks. Maybe minor modes. As you've seen, the code to "get back to using etags" is trivial. >> Would it not depend on major mode at all, so it would also be true >> in help-mode and similar buffers? > > Sometimes, I guess. Like doing that in *scratch* after "emacs -Q", or > in the *Help* buffer (which sometimes refers to external library > functions). Right. You'll only need to worry about help-mode buffers after someone writes dedicated xref support for it, and if you want to ignore their effors (just like it seems elisp-xref-find is not valuable for you). > Is it possible to turn on xref-etags-mode (or its equivalents) > globally? It's "turned on" by default. All it does is restore the default values of two variables, to get back to the default behavior in emacs-lisp-mode buffers. (I don't understand why this is not blindingly obvious from looking at those several lines.) > Are there any disadvantages of that? The find-func package is generally considered better and easier for Emacs Lisp navigation than etags. It's more precise, it distinguishes between different kinds of symbols, AND it can easily visit definitions from third-party code loaded in user's Emacs. The one downside (it won't offer non-autoloaded symbols from not loaded packages) doesn't seems to be a real problem in practice. Compared to etags, it also won't jump to the C functions that are not exposed to Emacs Lisp. The overwhelming majority of our users (myself probably included), won't ever need this.