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 (Was: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions) Date: Sun, 25 Jan 2015 00:26:39 +0200 Message-ID: <837fwbstls.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422138435 18889 80.91.229.3 (24 Jan 2015 22:27:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Jan 2015 22:27:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 24 23:27:14 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 1YF9Af-0000pH-B2 for ged-emacs-devel@m.gmane.org; Sat, 24 Jan 2015 23:27:13 +0100 Original-Received: from localhost ([::1]:36271 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF9Ae-0004mM-NV for ged-emacs-devel@m.gmane.org; Sat, 24 Jan 2015 17:27:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF9AR-0004m6-6b for emacs-devel@gnu.org; Sat, 24 Jan 2015 17:27:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YF9AN-0007fh-VD for emacs-devel@gnu.org; Sat, 24 Jan 2015 17:26:59 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:43208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YF9AN-0007fb-Hv for emacs-devel@gnu.org; Sat, 24 Jan 2015 17:26:55 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NIP00600CGE2E00@mtaout29.012.net.il> for emacs-devel@gnu.org; Sun, 25 Jan 2015 00:23:28 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIP004SACV4MC20@mtaout29.012.net.il>; Sun, 25 Jan 2015 00:23:28 +0200 (IST) In-reply-to: <54C3E7B6.2020006@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:181731 Archived-At: > Date: Sat, 24 Jan 2015 20:43:02 +0200 > From: Dmitry Gutov > CC: emacs-devel > > > 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. > > Personally, I consider that handwavy thinking a problem. We can't > support each and every approach and expect the user not to be > overwhelmed trying to remember and be able to use all of them. If we succeed in parameterizing the space of possible approaches, and let users specify what parameters they want, then yes, we can. 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 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. 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. > Even if situations where given limitations are bad can exist, as long as > they are rare enough, we can sacrifice certain edge cases if what's left > is a coherent, simple user interface. If we must. But I don't think this situation is one of those cases. I think simple yet powerful solutions are at hand here. > > 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. > > Ideally, we should provide extensible interfaces. Ideally, the popular extensions should already be there. Working on several packages at the same time is not an uncommon use case.