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: Sat, 24 Jan 2015 11:40:57 +0200 Message-ID: <83h9vgsehi.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> <83twzhryyq.fsf@gnu.org> <54C2C9DC.1050908@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422092532 8962 80.91.229.3 (24 Jan 2015 09:42:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Jan 2015 09:42:12 +0000 (UTC) Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 24 10:42:11 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 1YExEI-0004xx-UM for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Jan 2015 10:42:11 +0100 Original-Received: from localhost ([::1]:34500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YExEI-0003zl-Dg for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Jan 2015 04:42:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YExEE-0003zg-5j for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 04:42:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YExEA-0001VK-PX for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 04:42:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YExEA-0001VG-LM for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 04:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YExEA-0000pW-2s for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 04:42: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: Sat, 24 Jan 2015 09:42: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.14220924703123 (code B ref 19466); Sat, 24 Jan 2015 09:42:01 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 24 Jan 2015 09:41:10 +0000 Original-Received: from localhost ([127.0.0.1]:54806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YExDI-0000oI-S1 for submit@debbugs.gnu.org; Sat, 24 Jan 2015 04:41:09 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:55889) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YExDA-0000na-It for 19466@debbugs.gnu.org; Sat, 24 Jan 2015 04:41:02 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NIO00N00D2A6300@mtaout26.012.net.il> for 19466@debbugs.gnu.org; Sat, 24 Jan 2015 11:40:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIO00MZ3DJYEV30@mtaout26.012.net.il>; Sat, 24 Jan 2015 11:40:47 +0200 (IST) In-reply-to: <54C2C9DC.1050908@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:98671 Archived-At: > Date: Sat, 24 Jan 2015 00:23:24 +0200 > From: Dmitry Gutov > CC: eller.helmut@gmail.com, 19466@debbugs.gnu.org > > On 01/23/2015 11:03 PM, Eli Zaretskii wrote: > > > I also like commands that work on the current project, I just don't > > like them to depend too much on the current buffer. > > To cut this part of discussion short, yes, the project system can well > be designed so that the "current project" depends not on the current > buffer but on the user's choice. So to switch between projects, you > invoke an explicit command, but don't visit a buffer belonging to the > other project. And xref can work with such a system (just as it works > with etags) without significant problems. Can you tell how can this be set up with xref, or point me to the relevant documentation? > > 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. > > Instead of xref plugging into whatever, any project system (which I'm > assuming is implemented as a minor mode) can plug into xref and set up > xref-find-function, etc, to use itself. Any of these two will do (a plug has 2 parts). > > 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. > > That depends on the backend's implementation. etags works that way. That's not my point. My point is that it is up to the user to decide when she switches projects, and tell Emacs about that. Emacs should not try doing that on its own, whatever the backend's implementation is. The backend cannot make this decision for the user. > I think it's high time you've tried the snippets I wrote. I said I will -- when I have time. I didn't have that time yet, sorry. > >> 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? > > You may not like it, but it's the easiest viable approach we can take, > and a lot of people find it natural. For instance, both original > proposals for the xref implementation used it. I believe you it's the easiest approach. But that doesn't yet make it viable, because IMO it doesn't scale. Only very simple projects will be happy with such a design. The example I described is not very complicated, either, but it already bumps into this limitation. I think this is a clear sign that the limitation should be lifted. > However, like I mentioned, when a project system is used, we can use its > backend in all project files, and so the backend would depend on the > directory you in. If lifting the above limitation requires some project system, then we should provide a simple one for a project that uses only Makefile's. That could be a single command that just specifies the top-level directory of the project, or something similar. However, it sounds like xref is not yet ready for that, either, is it? If so, I suggest to add these simple features, because that would allow to lift the limitation and make the feature much more scalable. > > projectile-switch-project is conceptually the same as > > visit-tags-table, so I see no difference. > > Except it visits the "root file" of the project after switching, and > immediately "forgets" the previous project. So it's the kind of design > you don't like. Then there should be a projectile-add-project and projectile-remove-project as well. I'm sure someone already thought about that. (I know nothing about Projectile, except that I think the name is unfortunate -- take this from someone who has an intimate familiarity with real projectiles.) > > 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. > > While I can understand it, that's just your (i.e. not universal) > opinion I'd be surprised if it was just mine. I know people who work on projects much more complex than the use case I described. Perhaps they don't use Emacs, which would be an indirect approval of my opinions. > That is, a backend can use this approach as well. "Can" and "does" have a large gap between them, from the user's POV. Do we already have such a backend? If not, I suggest to add it. > > That's not user-level customization. It's too complex to be that. We > > need simpler, higher-level customizations. > > We don't even know what and how to customize yet. It might be time for > you to swap the user shoes for the developer shoes. Unlikely to happen. Given that etags exists and pretty much satisfies my needs (with 30-year old technology!), there's not enough itch here for me to scratch. If xref is going to be as good as etags, let alone better, I _will_ switch, I can promise you that much. Until then, I'm happy enough with etags, thank you very much. I'm here merely as a user, providing feedback for features someone else develops. I hope this is helpful; if not, feel free to discontinue the discussion at any point you like. > >>> 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? > > Because emacs-lisp-mode overrides it, and to reach certain level of > happiness, you seem to need to revert that override. I believe I've > explained that in the previous email, no? No, I only understood that now. Sorry for being dense. So perhaps some users, like myself, will benefit from preventing the override? Is that possible with the current master? > > 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. > > You seem to be clamoring for project support in Emacs. Maybe I am, I don't know. I don't care how this is called. What I do care is to be able to start working on a project with minimal fuss. Having to spend a significant time telling Emacs just what constitutes the project is therefore a turn-off: it is why I dislike Visual Studio like "projects" and "solutions" system -- it might be OK for starting a project from scratch, but sucks when you need to work on an existing project, let alone a large one. > That's commendable, and it's a separate discussion. It is a very much related discussion, since you think the features I miss in xref should be implemented by "project support". Because etags seems to seamlessly let me have that. So if xref is meant to replace etags, it should provide the same functionality, and if that requires some rudimentary "project support", we should include it when we announce deprecation of etags. > Meanwhile, a lot of features currently depend just on the current major > mode and buffer. There's nothing new about it. I never said that no feature can ever depend on the major mode. All I'm saying is that this particular feature shouldn't, and I gave simple enough use cases to demonstrate why it is IMO wrong in this case. > The easiest example is code completion. In emacs-lisp-mode, it will > parse the current buffer context and offer completions from obarray, > somewhat filtered. If you have a README in the same directory as > foo.el (so we might consider them to be in the same project), when > you open it, you definitely won't get the same completions as in > emacs-lisp-mode. In fact, if there's no current tags file visited, > in the default Emacs configuration you won't get any completions at > all. > > Similarly for python-mode (python-shell-completion-at-point only works > in Python buffers, and only when an inferior shell is running). Likewise > for Octave, and I just haven't looked at Guile, Awk and GDB support. I'm not sure what completions are alluded to here. Completions are context-dependent, i.e. their DWIM-ish nature should depend on what is being completed, and for what purposes. For example, I hope you'd agree that it would be bad in general for completion in "C-x C-f" to show only files from the current project. By contrast, a specialized command that is meant to find files only from the current project should probably limit the candidates to the project. Likewise with symbols -- when the user wants only symbols from the current project, or from the programming language of the current buffer, that's what Emacs should show. But there are also situations where such limitations produce bad results. Since only the user knows what she wants to see at any given moment, Emacs must support that. It can do that in several ways: . have dedicated commands for each kind of situation . apply some heuristics to order the candidates in a particular way, so that the ones deemed more DWIM-ish appear first; this heuristics could use the current major mode or the current project or something else . maybe some other possibilities I haven't thought about The important point is we cannot limit the user to just one possible context, even if it is the most frequent one. Such a feature would be too limited.