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: Sat, 24 Jan 2015 00:23:24 +0200 Message-ID: <54C2C9DC.1050908@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> <54C28635.8070606@yandex.ru> <83twzhryyq.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 1422051854 25416 80.91.229.3 (23 Jan 2015 22:24:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 22:24:14 +0000 (UTC) Cc: 19466@debbugs.gnu.org, eller.helmut@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 23:24: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 1YEmeA-0005SI-U0 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 23:24:11 +0100 Original-Received: from localhost ([::1]:33382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmeA-0004U7-F7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 17:24:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEme6-0004U1-2R for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 17:24:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEme2-0006c9-Qv for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 17:24:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEme2-0006c5-Nw for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 17:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YEme2-000800-ID for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 17:24: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 22:24: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.142205181430712 (code B ref 19466); Fri, 23 Jan 2015 22:24:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 23 Jan 2015 22:23:34 +0000 Original-Received: from localhost ([127.0.0.1]:54673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmda-0007zH-64 for submit@debbugs.gnu.org; Fri, 23 Jan 2015 17:23:34 -0500 Original-Received: from mail-we0-f170.google.com ([74.125.82.170]:48841) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmdY-0007z3-5T for 19466@debbugs.gnu.org; Fri, 23 Jan 2015 17:23:32 -0500 Original-Received: by mail-we0-f170.google.com with SMTP id x3so28384wes.1 for <19466@debbugs.gnu.org>; Fri, 23 Jan 2015 14:23:26 -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=cxsFxsM7zjxjwg3kTvNnRGVq9VPr0Byre+ooSd1xW8c=; b=Gq6H+N7yWdEvFiDR6dvgI2IS3W3sjYDwialJ3FRIZb7zVWRVifkdsM7J3MsHAkn4jt YKs+83OA5qyk0PVEf4em8pRLNjbaBFEIcccgD9m7o6m0NCk/eRcyL8dhe7RnPM4hLBmm C37Dp6fLFcWCmIjkUpOFsY61opVEf0qRxAPUz5CacWyKFgyj0W1F/MaxPtwdyfKcYy1I d8HPdMiotSNRswhtKvNQRBlbWdP8VJIl4V1vbCsnBNyck9IooqPeInOqYsyiAuzlOtBR dxlCbZP29HfZce49RApAJKAd9kHGbbPhDmwdqzo3HBX/Hs69KhlnT2V0W+UX6jW08aoU Zo8A== X-Received: by 10.180.109.79 with SMTP id hq15mr8099410wib.47.1422051806569; Fri, 23 Jan 2015 14:23:26 -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 k1sm3887398wjn.9.2015.01.23.14.23.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 14:23:25 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <83twzhryyq.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:98660 Archived-At: 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. > 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. > 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. >> 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. etags-xref-find, likewise, will ask you for the path to the TAGS file, if it's not set yet. > 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. Semi-joke, yes. That's just what I often do to avoid the clutter of buffers opened from different projects. It could work almost as well using different frames, but I'd have to find a way to hide the one frame's file buffers from the other frames. You can continue doing what you've always done, no problem. >> 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. Not at all. When I say "etags backend", I mean "etags backend for xref", since the latter is the subject of our discussion. I think it's high time you've tried the snippets I wrote. >> 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. 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. But also see my first paragraph in this email. > 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. It's the most popular project solution for Emacs that I know. > 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, and I believe it's addressed above. That is, a backend can use this approach as well. > 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. >>> 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? >> 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. I can, and I do. > 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. That's commendable, and it's a separate discussion. Meanwhile, a lot of features currently depend just on the current major mode and buffer. There's nothing new about it. 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.