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: Fri, 23 Jan 2015 11:03:14 +0200 Message-ID: <83r3uluawd.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422003857 7457 80.91.229.3 (23 Jan 2015 09:04:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 09:04:17 +0000 (UTC) Cc: eller.helmut@gmail.com, 19466@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 10:04: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 1YEa9z-0001Ag-Eb for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 10:04:11 +0100 Original-Received: from localhost ([::1]:57715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEa9y-0004bd-Mc for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 04:04:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEa9u-0004Zy-7b for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 04:04:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEa9q-0000cZ-Qn for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 04:04:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEa9q-0000cV-OA for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 04:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YEa9q-0005st-94 for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 04:04: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: Fri, 23 Jan 2015 09:04: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.142200382922589 (code B ref 19466); Fri, 23 Jan 2015 09:04:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 09:03:49 +0000 Original-Received: from localhost ([127.0.0.1]:53475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEa9d-0005sH-6U for submit@debbugs.gnu.org; Fri, 23 Jan 2015 04:03:49 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:62883) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEa9Z-0005rn-Nk for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 04:03:47 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NIM00D00GZDRI00@a-mtaout20.012.net.il> for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 11:03:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIM00DNPH5CQN20@a-mtaout20.012.net.il>; Fri, 23 Jan 2015 11:03:13 +0200 (IST) In-reply-to: <54C1655E.4050403@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:98620 Archived-At: > Date: Thu, 22 Jan 2015 23:02:22 +0200 > From: Dmitry Gutov > CC: rudalics@gmx.at, 19466@debbugs.gnu.org, eller.helmut@gmail.com > > On 01/22/2015 08:02 PM, Eli Zaretskii wrote: > > > What I need is a way to find definitions of both C and Lisp symbols > > (functions, macros, struct's, etc.) irrespective of the current > > buffer's major mode. If xref can do that, it's fine with me. > > Would it also be irrespective of the current file, or its project? 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. 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). 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". But I doubt that this can be done reliably enough to satisfy users like me, when a project doesn't have a definitive description of what is or isn't part of it. 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)? 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. 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? > 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). > If you want it in all major modes, you can use find-file-hook instead of > emacs-lisp-mode-hook. If in all files everywhere, then you can also drop > the buffer-file-name check, ending up with > > (add-hook 'find-file-hook #'xref-etags-mode t) > > That doesn't help with non-file buffers, though. But you can use a > separate major mode hook for each. Is it possible to turn on xref-etags-mode (or its equivalents) globally? Are there any disadvantages of that? IOW, why does it need to be turned on by a hook?