From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates 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:39:17 -0500 Message-ID: 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> <838ugkn62m.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113a838230f146050ddebb16 X-Trace: ger.gmane.org 1422625183 15587 80.91.229.3 (30 Jan 2015 13:39:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Jan 2015 13:39:43 +0000 (UTC) Cc: Emacs developers , Brief Busters To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 30 14:39:42 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 1YHBnQ-0006Xh-2K for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2015 14:39:40 +0100 Original-Received: from localhost ([::1]:36799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHBnP-0007u0-H6 for ged-emacs-devel@m.gmane.org; Fri, 30 Jan 2015 08:39:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHBn8-0007tv-Fr for emacs-devel@gnu.org; Fri, 30 Jan 2015 08:39:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YHBn6-00025g-Rj for emacs-devel@gnu.org; Fri, 30 Jan 2015 08:39:22 -0500 Original-Received: from mail-yk0-x236.google.com ([2607:f8b0:4002:c07::236]:36331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHBn4-00025J-H0; Fri, 30 Jan 2015 08:39:18 -0500 Original-Received: by mail-yk0-f182.google.com with SMTP id q9so17123410ykb.13; Fri, 30 Jan 2015 05:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/wbo5dc5JEiQ9bJrOv5B2XsAc0PyezemhtNM7W5z0yU=; b=QkiEP2panavquSfAxn8mptBBn4rC2m3hcLYQwCa59t8miJb1s0CXBI9W7TDwmnhogF tL+eUCe+d4j6lcnLzwHj0pR7bLRyBmp1NoHHOPDENr5j6oMIe8GPGZUHa1r4bS7mNnuu kXv7tLSgOewfHv5/+tjT4QZGrDtKbjDpbZc/Q98EnYPJ7FlHQf4mO1NxagYlPHW1Fvox peA3miCfqar91zoJ6N35JaU50sSDNHiP+raQYQl/xFVxhCTqoRuQCFo17hbBoXF8aJbi R0Im5qo+wsMIGIgMZhsC5I8xz1NK0ElYRKEfE2vMqr5x93rEcfUhYMyjbHHIAbENI5WQ aAMg== X-Received: by 10.170.83.11 with SMTP id z11mr3319947ykz.91.1422625157999; Fri, 30 Jan 2015 05:39:17 -0800 (PST) Original-Received: by 10.170.204.78 with HTTP; Fri, 30 Jan 2015 05:39:17 -0800 (PST) In-Reply-To: <838ugkn62m.fsf@gnu.org> X-Google-Sender-Auth: mENplvL4ky9iGHQ3Xw-kaYMEic0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::236 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:182054 Archived-At: --001a113a838230f146050ddebb16 Content-Type: text/plain; charset=UTF-8 JY> To me your proposed model of "add project" / "remove project" seemed JY> just too reminiscent of etag's paradigm for managing tag tables. EZ> There's nothing inherently wrong with that, is there? JY> Of late I have been using git-new-workspace. In that setting JY> find-tag forever seems to open the _wrong_ file. More perniciously JY> it often opens one that looks right though in a different workspace, JY> thereby slowing me down and making me paranoid. EZ> I never used git-new-workspace, so I don't really understand what you EZ> describe here. In any case, this sounds like a problem with the EZ> program that created the TAGS file, not with find-tag per se: the EZ> latter just obeys what's in the database. EZ> And I'd still want to know what are the problems with the stateful EZ> approach I proposed. The historic way to use git to do work across different branches within a single code base is to multiplex a single workspace. This means that at any instant one has available only a single branch and a single set of (possibly out of date) tags. Assume then that I have branches B1 and B2, along with tag T defined in file F1 and referenced in file F2. I generate a tags database while I have branch B1 checked out. I later switch to branch B2 though I do not rebuild nor my tags database. I open file F2 open and want to visit the definition of tag T. My tags database, though somewhat out of date (it describes branch B1), correctly opens B2's version of file F1 (the only version available) and if I am lucky still gets me to T's definition. The git-new-workstation script automates setting up light weight per branch workspaces. (They are light weight primarily in the sense that they share a single history database stored in a common parent workspace.) This arrangement enables multiplexing work across multiple directories merely by opening a different path. Note: no need even to cd to a different directory. So now there are multiple copies of every file, some different, most identical, in congruent directory trees. Going back to my earlier example using git-new-workspace I would now have two workspaces, B1 and B2, corresponding to my two branches, each containing files F1 and F2 and each containing an up to date tags database. I perform some work in B1 with the net effect that I have a loaded tags table describing B1. I then visit B2::F2, do some work involving tag T causing me to want to visit T's definition. At this point C-. takes me to T's definition in B1::F1, not in B2::F1 as I would want. The problem is that both files exist on my disk and are similar if not identical. Thus, unless I am especially vigilant, I edit and save the wrong file. To reiterate my effort to switch branch contexts was nothing more than C-x C-f or C-x b. Given the current tags implementation getting emacs to use the correct tags database involves explicit manipulation of session state via visit-tags-table. Hence my gripe about statefulness. I hope that helps, /john --001a113a838230f146050ddebb16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
JY> To me your proposed model of "add project"= ; / "remove project" seemed
JY> just too reminiscent of eta= g's paradigm for managing tag tables.

EZ> There's nothing= inherently wrong with that, is there?

JY> Of late I have been us= ing git-new-workspace. In that setting
JY> find-tag forever seems to = open the _wrong_ file. More perniciously
JY> it often opens one that = looks right though in a different workspace,
JY> thereby slowing me d= own and making me paranoid.

EZ> I never used git-new-workspace, s= o I don't really understand what you
EZ> describe here.=C2=A0 In = any case, this sounds like a problem with the
EZ> program that create= d the TAGS file, not with find-tag per se: the
EZ> latter just obeys = what's in the database.

EZ> And I'd still want to know wh= at are the problems with the stateful
EZ> approach I proposed.
The historic way to use git to do work across different branch= es within a single code base is to multiplex a single workspace.=C2=A0 This= means that at any instant one has available only a single branch and a sin= gle set of (possibly out of date) tags.=C2=A0 Assume then that I have branc= hes B1 and B2, along with tag T defined in file F1 and referenced in file F= 2.=C2=A0 I generate a tags database while I have branch B1 checked out.=C2= =A0 I later switch to branch B2 though I do not rebuild nor my tags databas= e.=C2=A0 I open file F2 open and want to visit the definition of tag T.=C2= =A0 My tags database, though somewhat out of date (it describes branch B1),= correctly opens B2's version of file F1 (the only version available) a= nd if I am lucky still gets me to T's definition.

<= div>The git-new-workstation script automates setting up light weight per br= anch workspaces. =C2=A0(They are light weight primarily in the sense that t= hey share a single history database stored in a common parent workspace.) = =C2=A0This arrangement enables multiplexing work across multiple directorie= s merely by opening a different path.=C2=A0 Note: no need even to cd to a d= ifferent directory.=C2=A0 So now there are multiple copies of every file, s= ome different, most identical, in congruent directory trees.=C2=A0 Going ba= ck to my earlier example using git-new-workspace I would now have two works= paces, B1 and B2, corresponding to my two branches, each containing files F= 1 and F2 and each containing an up to date tags database.=C2=A0 I perform s= ome work in B1 with the net effect that I have a loaded tags table describi= ng B1.=C2=A0 I then visit B2::F2, do some work involving tag T causing me t= o want to visit T's definition.=C2=A0 At this point C-. takes me to T&#= 39;s definition in B1::F1, not in B2::F1 as I would want.=C2=A0 The problem= is that both files exist on my disk and are similar if not identical.=C2= =A0 Thus, unless I am especially vigilant, I edit and save the wrong file.<= /div>

To reiterate my effort to switch branch contexts w= as nothing more than C-x C-f or C-x b.=C2=A0 Given the current tags impleme= ntation getting emacs to use the correct tags database involves explicit ma= nipulation of session state via visit-tags-table.=C2=A0 Hence my gripe abou= t statefulness.

I hope that helps,

<= /div>
/john


--001a113a838230f146050ddebb16--