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 18:47:46 +0200 Message-ID: <54C3CCB2.5030708@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> <54C2C9DC.1050908@yandex.ru> <83h9vgsehi.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 1422118092 31258 80.91.229.3 (24 Jan 2015 16:48:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Jan 2015 16:48:12 +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 Sat Jan 24 17:48: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 1YF3sY-0006u5-IA for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Jan 2015 17:48:10 +0100 Original-Received: from localhost ([::1]:35463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF3sY-00021x-1i for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Jan 2015 11:48:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF3sU-00021q-5H for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 11:48:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YF3sQ-0004H9-SM for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 11:48:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF3sQ-0004H3-PJ for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 11:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YF3sQ-0003j1-Do for bug-gnu-emacs@gnu.org; Sat, 24 Jan 2015 11:48: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: Sat, 24 Jan 2015 16:48: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.142211807814308 (code B ref 19466); Sat, 24 Jan 2015 16:48:02 +0000 Original-Received: (at 19466) by debbugs.gnu.org; 24 Jan 2015 16:47:58 +0000 Original-Received: from localhost ([127.0.0.1]:55328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YF3sL-0003ig-OJ for submit@debbugs.gnu.org; Sat, 24 Jan 2015 11:47:58 -0500 Original-Received: from mail-wi0-f170.google.com ([209.85.212.170]:35245) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YF3sJ-0003iT-8W for 19466@debbugs.gnu.org; Sat, 24 Jan 2015 11:47:56 -0500 Original-Received: by mail-wi0-f170.google.com with SMTP id em10so727398wid.1 for <19466@debbugs.gnu.org>; Sat, 24 Jan 2015 08:47:49 -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=8uLTYtcFA3vzIi4mvUUKQK7cVtk2O7YWQtNsmp1cwFs=; b=Zdv/pcBIcYjktIxmw/Q/0a959/7WFIQrMUnM8nU7ez59QrahrsUNm67A8XsLacxeMw 5PCNiBTVMGR907hvx0/yjNCCHarE1i3J55z/Q74YxH5rFyl+Sg6zOUwNM4iw//d43l28 gc7DFZRvgQWOkzqzka8M/oIyvxITcmYQY0iUgVxvinG5QKufogbUETa5BsRSvFQpLcfb k1SL3WtuZP0rNXGANgPyce8UFfq12mtDCOQP5OlXZ1nHQt7WgH2SLTrbP8BywO7HfCMP +CBXoXKZ2J3ggjoqi1q3lkpWO5FTSupOOPHBYzXBx+MzhmBqd17IRPP75LW+WAHQCRuY Qgag== X-Received: by 10.180.36.226 with SMTP id t2mr15384321wij.16.1422118069616; Sat, 24 Jan 2015 08:47:49 -0800 (PST) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id bj3sm6499942wib.3.2015.01.24.08.47.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 08:47:49 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <83h9vgsehi.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:98678 Archived-At: On 01/24/2015 11:40 AM, Eli Zaretskii wrote: >> 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? I did. "Just like it works with etags" was a big hint in the quote above. > I said I will -- when I have time. I didn't have that time yet, > sorry. Please respond after you've found that time, then. Is it is, the current discussion is getting nowhere. > 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. Just for the sake of the argument: instead of visiting two tag tables at the same time from Emacs, you could instead include the external library's tag file in the application's tag file ("--include" etags argument). That doesn't seem like it'll work with several external libraries, but maybe it should. That wouldn't allow you to jump from a library file to the application's file (I think; you'd have to use e.g. switch-buffer instead), but there is a certain semantic strictness in that (the library doesn't know about the application). > 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. It's quite ready. xref will work with any such backend. > Then there should be a projectile-add-project and > projectile-remove-project as well. I'm sure someone already thought > about that. Maybe they didn't but they haven't shared that with the rest of us. Given Projectile's current behavior, though it would cause incompatibility or complications in the implementation. But anyway, I think I'm starting to like the idea of this approach. Maybe I'll try to implement it sometime. > (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.) I think it's fine. A projectile is not necessarily an ammo round. >> 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. etagggggsss. Its only drawback, from your standpoint, stems from it being the default one (which major modes can override), instead from being assigned in a globalized minor mode. I'm not sure if we want to have it both as default, and have a minor mode (a by-default-on minor mode won't be good enough). > 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. I you were just a user, I'd have stopped a while ago, since I still don't think this feature request is useful to the majority of users. Since you're a valued core contributor, though, I'd really like to accommodate your needs. However, that comes with the expectation that you can participate in the design and provide more nuanced requirements than an ordinary user would do. Maybe you'd a least look at the code, if not implement the improvements yourself. > So perhaps some users, like myself, will benefit from preventing the > override? Is that possible with the current master? Yes: you use the snippets I provided together with the current master. Whether any part of them is worthy of installing into master, is yet to be determined. > 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. I'm pretty sure some users would consider having to call visit-tags-table as "having to spend time telling Emacs just what constitutes a project", as opposed to Projectile's current approach. > It is a very much related discussion, since you think the features I > miss in xref should be implemented by "project support". No: the xref features should work with etags without additional infrastructure. We won't know that for certain, though, until you find that free time. I mentioned project support, which we don't have, because you've expanded the discussion to supporting "this mode of work" in different languages and, I'm assuming, for different features. And not every language/framework ecosystem considers the tag files to be the best solution for code navigation, completion, etc. I'll respond to the rest of this email in a separate thread, but that discussion is likely premature. > 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. xref is meant to replace `find-tag' and `tags-apropos'. etags, as a package, is unlikely to ever be deprecated.