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: Fri, 30 Jan 2015 08:19:45 +0200 Message-ID: <838ugkn62m.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> <83twzerges.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1422598814 30232 80.91.229.3 (30 Jan 2015 06:20:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Jan 2015 06:20:14 +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 Fri Jan 30 07:20:12 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 1YH4w8-0006nG-Df for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2015 07:20:12 +0100 Original-Received: from localhost ([::1]:34934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH4w7-0003Yg-AN for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2015 01:20:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH4vt-0003Yb-R5 for emacs-devel@gnu.org; Fri, 30 Jan 2015 01:19:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YH4vq-0007dW-He for emacs-devel@gnu.org; Fri, 30 Jan 2015 01:19:57 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:57713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH4vq-0007dL-9G for emacs-devel@gnu.org; Fri, 30 Jan 2015 01:19:54 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NIZ00E007Z28V00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Fri, 30 Jan 2015 08:19:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIZ00EVE88Z5H60@a-mtaout23.012.net.il>; Fri, 30 Jan 2015 08:19:47 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:182018 Archived-At: > Date: Thu, 29 Jan 2015 16:19:19 -0500 > From: John Yates > Cc: Brief Busters , Emacs developers > > EZ> For example, it sounds to me that by having an "add project" and > EZ> "remove project" commands, we can give the user the ability to tell > > JY> Such a model is inherently stateful, hence problematic. It makes > JY> multiplexing work on multiple projects difficult and error-prone. > > EZ> Stateful, yes. Working on a certain project or a set of projects is > EZ> indeed inherently stateful. > EZ> > EZ> I don't see the problematic part in that, though. Could you elaborate > EZ> on what practical problems you see with this? > > Eli, > > To me your proposed model of "add project" / "remove project" seemed > just too reminiscent of etag's paradigm for managing tag tables. There's nothing inherently wrong with that, is there? > Of late I have been using git-new-workspace. In that setting > find-tag forever seems to open the _wrong_ file. More perniciously > it often opens one that looks right though in a different workspace, > thereby slowing me down and making me paranoid. I never used git-new-workspace, so I don't really understand what you describe here. In any case, this sounds like a problem with the program that created the TAGS file, not with find-tag per se: the latter just obeys what's in the database. And I'd still want to know what are the problems with the stateful approach I proposed.