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 18:09:15 +0200 Message-ID: <83twzerges.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 1422202220 3305 80.91.229.3 (25 Jan 2015 16:10:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Jan 2015 16:10:20 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 25 17:10:15 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 1YFPlH-0006iG-U9 for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 17:10:08 +0100 Original-Received: from localhost ([::1]:38123 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFPlH-0005jB-1S for ged-emacs-devel@m.gmane.org; Sun, 25 Jan 2015 11:10:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFPko-0005RX-UC for emacs-devel@gnu.org; Sun, 25 Jan 2015 11:09:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFPkk-0007sO-Pm for emacs-devel@gnu.org; Sun, 25 Jan 2015 11:09:38 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:42347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFPkk-0007rv-C2 for emacs-devel@gnu.org; Sun, 25 Jan 2015 11:09:34 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NIQ00H00PU3DF00@mtaout27.012.net.il> for emacs-devel@gnu.org; Sun, 25 Jan 2015 18:02:39 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIQ006TVPWFK090@mtaout27.012.net.il>; Sun, 25 Jan 2015 18:02:39 +0200 (IST) In-reply-to: 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.183 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:181753 Archived-At: > Date: Sat, 24 Jan 2015 19:21:19 -0500 > From: John Yates > Cc: Eli Zaretskii , Emacs developers > > On 01/25/2015 12:26 AM, Eli Zaretskii wrote: > 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 > > Such a model is inherently stateful, hence problematic. It makes multiplexing work on multiple projects difficult and error-prone. Stateful, yes. Working on a certain project or a set of projects is indeed inherently stateful. I don't see the problematic part in that, though. Could you elaborate on what practical problems you see with this? > I believe some would still prefer just having it inferred. > > Yes, please! Absolutely. I thought I described a use case where automatic inference is inherently limited and error-prone. However, we could have both modes of operation, the automatically inferred one for simple use cases, and the manual mode for more complex ones. There's no need to choose and support only one. > If the projects are unrelated, personally I'd rather keep them separate. > > Me too. Me too, but sometimes it makes sense not to.