From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Project support and completions Date: Sun, 25 Jan 2015 18:08:15 +0200 Message-ID: <83vbjurggg.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> <83h9vgsehi.fsf@gnu.org> <54C3E7B6.2020006@yandex.ru> <837fwbstls.fsf@gnu.org> <54C429D8.6010302@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422202185 2544 80.91.229.3 (25 Jan 2015 16:09:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Jan 2015 16:09:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 25 17:09:44 2015 Return-path: Envelope-to: ged-emacs-devel@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 1YFPku-0006Hb-1W for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 17:09:44 +0100 Original-Received: from localhost ([::1]:38121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFPkt-0005IV-EP for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 11:09:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFPkf-0005IK-ER for emacs-devel@gnu.org; Sun, 25 Jan 2015 11:09:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFPkY-0007l5-5t for emacs-devel@gnu.org; Sun, 25 Jan 2015 11:09:29 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:41392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFPkX-0007kf-Op for emacs-devel@gnu.org; Sun, 25 Jan 2015 11:09:22 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NIQ00400PYME600@mtaout29.012.net.il> for emacs-devel@gnu.org; Sun, 25 Jan 2015 18:05:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIQ002IRQ0FVK10@mtaout29.012.net.il>; Sun, 25 Jan 2015 18:05:03 +0200 (IST) In-reply-to: <54C429D8.6010302@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181752 Archived-At: > Date: Sun, 25 Jan 2015 01:25:12 +0200 > From: Dmitry Gutov > CC: emacs-devel@gnu.org > > For example, it sounds to me that by having an "add project" and > "remove project" commands, we can give the user the ability to tell > > A specific project solution could provide those commands. I'd be surprised if they didn't already. > which projects' databases of symbols are relevant to what she is doing > now. Then Emacs can select completion candidates from the list of > projects currently in the active set. > > This introduces a new constraint on the potential "project" API. While we want to be able to list files or buffers (and maybe do something with their contents) from all current projects, there are commands in Projectile that necessarily work just on one directory, such as: > > - Visit project in Dired. > - Run a build tool, ag, grep, or any plain shell command in root. > - Run vc-dir in root. > - (Might or might not also fit the description) Regenerate tags. > > So the project API either has to be able to designate one project as the "main one" while implementing "list all files" differently, or dynamically look up the real current project root, to use in those commands. I agree. However, for the purposes of this discussion, all that is needed is for xref to expose some interface that would allow a project API to tell xref which databases to use. Then this interface could be used even if no project system is in use, from user-level commands or other features. The important aspect of this is that at least in some situations the set of databases to use for symbol completion should be dictated by some code outside xref that uses an interface provided by xref, and not necessarily inferred automatically. > Such a paradigm will not > overwhelm users, since knowing which packages one is working on at any > given time is something we all do anyway. > > I believe some would still prefer just having it inferred. Then this mode should also be provided. But since it has inherent limitations, it cannot be the only one. > Ideally, the popular extensions should already be there. Working on > several packages at the same time is not an uncommon use case. > > If the projects are unrelated, personally I'd rather keep them separate. What do you mean by "unrelated" and by "separate" here? Suppose there's some bug when Emacs calls a GnuTLS function. Does working on both of them trying to solve the bug makes them "related"? Do you agree that being able to browse and complete on symbols from both of them might be very useful in this use case? > Or, in the example you've given before (application and a library it uses), at least with certain languages/environments the project solution could automatically infer all the libraries used by the current application, as well as their current sources, from the project file. That would make add-project and remove-project commands unnecessary, leaving only select-project. Such automatic inference is not easy. Library dependencies come in several forms: linking in a Makefile, dynamic loading in the sources, dependencies in pkg-config style *.pc files, etc. Also, some libraries depend on other libraries. Discovering all those dependencies sounds like a non-trivial project to me. More importantly, most of the time when I work on the application, I don't care about symbols in the libraries used by an application. So doing what you suggest would fill my "namespace" with many symbols I don't care about and don't want to see as completion candidates. As an extreme example, consider libc, the Standard C library, which any C program uses, or the Standard C++ library. Is it really a good idea for xref to offer all those when the user types 'M-.'? OTOH, when I work on an interface between the application and a library, then I do want the symbols of that single library to appear as completion candidates. Once again, I don't think this can be resolved automatically in a satisfactory manner, at least not in all important use cases. So a provision for manual instruction by the user is still required, IMO.