From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregor Kappler Subject: Re: org-git-link does not support locational information within file Date: Tue, 15 Feb 2011 21:11:19 +0100 Message-ID: <87aahx9hy0.fsf@univie.ac.at> References: <877hdh2m7a.fsf@univie.ac.at> <87zkq2trqx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=52477 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpREb-0003Z0-Kk for emacs-orgmode@gnu.org; Tue, 15 Feb 2011 15:10:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PpREa-0004eA-0P for emacs-orgmode@gnu.org; Tue, 15 Feb 2011 15:10:53 -0500 Received: from grace.univie.ac.at ([131.130.3.115]:52305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PpREZ-0004dW-CY for emacs-orgmode@gnu.org; Tue, 15 Feb 2011 15:10:51 -0500 In-Reply-To: <87zkq2trqx.fsf@gnu.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org Hi Bastien, Thanks for your answer. I was surprised and glad to hear so much interest i= n=20 my particular problem. On Fri, 11 Feb 2011 18:17:58 +0100, Bastien w= rote: > > 2. use git versioned files transparently, i.e. org-git-store-link > > should support search (org-ids and text files) in linked git > > revisions of files. >=20 > I've look into this. We could code things to add a search string: >=20 > [[git:~/my.org::master@{2011-02-07}::Org code]] > ^^ >=20 > ... but I'm reluctant to change the general syntax of links, even=20 > if that's just for git links. It might be better to stick to org-mode's convention of storing the "locati= on within the file" after "::", a convention your current syntax is not adh= ering to. I think you could stay consistent with the current general syntax of orgmod= e by switching from [[git:~/my.org::master@{2011-02-11}::Org code]] to [[git:~/my.org@master{2011-02-11}::Org code]] or=20 [[git:~/my.org?master{2011-02-11}::Org code]] This would fully break existing links. Achim Gratz contributed some good points about changing the git-link syntax= and made a more founded proposal for a changed syntax though. Achim seems = to focus strongly on machine readability. For me, I like to be able to read= links easily. [[git:?::]] can be - a date+time value (for me, time is important here) - a SHA - "HEAD" >=20 > > 3. define an interactive function that can update the revision > > information of a link at mark to the current branch head of the > > file (so I can update all links to new FS folder structure.) >=20 > You mean update >=20 > [[git:~/my.org::master@{2011-02-07}::Org code]] >=20 > to=20 >=20 > [[git:~/my.org::master@{2011-02-11}::Org code]] >=20 > ? >=20 > Can you provide an explicit example? Let the function be of name org-git-link-update-to-head. I will adhere to the syntax in your post.=20 I guess all scenarios can be made explicit by two conditions: 1. The file is still of the same name. Calling org-git-link-update-to-head = on=20 [[git:~/my.org::master@{2011-02-11}::Org code]] would change the link to [[git:~/my.org::master@{2011-02-15}::Org code]] (today being the 15th) 2. more interesting is the case that the file was moved by e.g by git mv my.org your.org Then optimally git would be queried for the actual location of a newer v= ersion in HEAD (if unique).=20 (I am actually not sure how to do this with git, but should be viable) The link should be rewritten by org-git-link-update-to-head to [[git:~/your.org::master@{2011-02-15}::Org code]] This file might have been edited meanwhile by e.g.=20 echo "* annoying tail heading" >> your.org && git add your.org && git co= mmit -m "" Still the new link should become [[git:~/your.org::master@{2011-02-14}::Org code]] If HEAD would be added to the possible revision definition, org-git-link-up= date-to-head cannot identify the file after moving. On the other hand, havi= ng this function one would not want to point to head. Another possibility would be not to rewrite links but to resolve the current revision as outlined on the fly in org-open-at-point. > > I am still lame at elisp - so my implementation skills are > > limited. With the great work in org-git-link all backend stuff seems > > there, only needing more glue. Any hints how to achieve this would be > > very welcome! >=20 > org-git-link.el is quite readable, and I'd welcome ideas on how to > extend it to fulfill your wishes without extending Org's link syntax=20 > too much... I try to learn elisp bit by bit. Found a good tutorial finally. I got busy times around me - need to constrain fiddle-time. Cheers and thanks, Gregor --=20 -- Dr. Gregor Kappler Fakult=C3=A4t f=C3=BCr Psychologie=20 Institut f=C3=BCr Entwicklungspsychologie und=20 Psychologische Diagnostik http://www.univie.ac.at/Psychologie Universit=C3=A4t Wien Liebiggasse 5 A-1010 Wien mail: gregor.kappler@univie.ac.at tel: +43 1 4277 47866