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 23:03:57 +0200 Message-ID: <83twzhryyq.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> <83r3uluawd.fsf@gnu.org> <54C28635.8070606@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422047119 13811 80.91.229.3 (23 Jan 2015 21:05:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 21:05:19 +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 22:05:15 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 1YElPk-00009r-16 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 22:05:12 +0100 Original-Received: from localhost ([::1]:33151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YElPj-0005Cd-BE for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 16:05:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YElPe-0005BS-1j for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:05:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YElPa-0002rm-Hd for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:05:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YElPa-0002rQ-DJ for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:05:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YElPZ-0004j7-W3 for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:05: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 21:05: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.142204704618098 (code B ref 19466); Fri, 23 Jan 2015 21:05:01 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 21:04:06 +0000 Original-Received: from localhost ([127.0.0.1]:54612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElOf-0004hp-4C for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:04:05 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:44906) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YElOb-0004hL-Mh for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 16:04:03 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NIN00I00ECQ9600@a-mtaout20.012.net.il> for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 23:03:55 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIN00IQVEII2Z70@a-mtaout20.012.net.il>; Fri, 23 Jan 2015 23:03:55 +0200 (IST) In-reply-to: <54C28635.8070606@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:98651 Archived-At: > Date: Fri, 23 Jan 2015 19:34:45 +0200 > From: Dmitry Gutov > CC: rudalics@gmx.at, 19466@debbugs.gnu.org, eller.helmut@gmail.com > > 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. I didn't mean conceptually, I meant in practice. Collecting all the bits and pieces of a project scattered across many Makefile's in a large tree is not an easy task. It's little wonder most if not all "project systems" use a single file to describe the entire project workspace. > > 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... I also like commands that work on the current project, I just don't like them to depend too much on the current buffer. E.g., I have a habit of switching to *scratch* quite often and leave random notes there, or text I'd like to have at my fingertips. That doesn't mean that when I'm in *scratch* I'm not working on the same project I was a minute ago and need to be able to access the same symbols. IOW, I find it hard to believe Emacs can be smart enough to know when I switch projects; at best it could employ some heuristics to offer me that for confirmation. Realistically, we need a command to switch to another project, and xref should plug into it, instead of trying to second-guess what I want. > > 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. It doesn't matter if there's one or many. The important part is that the active one(s) need to be switched when I change to another project, and otherwise kept until I say-so. > If you're using the etags backend, it should be just as affected by > `M-x visit-tags-table', as `find-tag' is. I don't understand what that means, sorry. find-tag cannot work without me visiting a TAGS table. > > 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. Blasphemy ;-) Seriously, though: I very much hope this was a semi-joke, because we really don't want asking users to do that. A single instance of Emacs should be able to cope with such a simple task. FWIW, I regularly have about a dozen projects in my Emacs session, and switch between them quite a lot. > But the tags-file-name/tags-table-list approach should still work, > as long as the etags backend is used. I thought you were asking whether I must stick to etags, and was trying to explain which features I need to have, not necessarily in etags. If the only conclusion from this discussion is that I must stick to etags or give up on features that it has been offering for years, then I'm sorry to say that xref doesn't seem progress to me. > Note that currently the only thing that depends on a specific buffer is > the backend used. I fail to understand the rationale behind such a design. As long as we are talking about buffers that hold source code of some programming language, why would it be a good idea to switch backends depending on the buffer? > > 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. projectile-switch-project is conceptually the same as visit-tags-table, so I see no difference. Not sure what kind of scaling is being alluded to here; in any case, I wasn't talking about finding files, although TAGS allow that as well (I never used that feature of etags). > 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. That's not the issue. The issue is that the logic behind determining the current project cannot be reliable enough to decide for the user which collection(s) of symbols are of interest to me at any given time. Only the user knows that. Unlike some other heuristics, where it's okay to have an imperfect success rate, in this case it's terribly annoying when Emacs refuses to admit that a symbol exists and show it to you, when you _know_ for sure it does exist. This kind of annoyance _will_ happen if you rely on automated logic for deciding which symbols are or aren't relevant. > > 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. That's not user-level customization. It's too complex to be that. We need simpler, higher-level customizations. > > Is it possible to turn on xref-etags-mode (or its equivalents) > > globally? > > It's "turned on" by default. Then why did you propose to use hooks? > 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. You can't build useful features on such assumptions. Btw, this mode of work, in more than one language, is not limited to Emacs. You will see it in Guile, in Python, in Awk, in GDB, and in many other places. It begins to be the rule rather than exception these days. It's not good if Emacs will ask developers to jump through hoops to support that.