From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Illiterate programming question Date: Fri, 01 Apr 2011 10:41:11 -0600 Message-ID: <8762qxc4bc.fsf@gmail.com> References: <4D93935B.1020402@sift.info> <8766.1301520804@alphaville.usa.hp.com> <4D93A425.9070604@sift.info> <87mxkcrzk7.fsf@gmail.com> <4998.1301602410@alphaville.usa.hp.com> <5975.1301636805@alphaville.dokosmarshall.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=51982 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5hPW-00013X-MC for emacs-orgmode@gnu.org; Fri, 01 Apr 2011 12:44:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5hPU-0004pf-7I for emacs-orgmode@gnu.org; Fri, 01 Apr 2011 12:41:21 -0400 Received: from mail-pz0-f41.google.com ([209.85.210.41]:53835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5hPT-0004pM-U1 for emacs-orgmode@gnu.org; Fri, 01 Apr 2011 12:41:20 -0400 Received: by pzk32 with SMTP id 32so959234pzk.0 for ; Fri, 01 Apr 2011 09:41:18 -0700 (PDT) In-Reply-To: <5975.1301636805@alphaville.dokosmarshall.org> (Nick Dokos's message of "Fri, 01 Apr 2011 01:46:45 -0400") 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: nicholas.dokos@hp.com Cc: Org Mode , rpgoldman@sift.info Nick Dokos writes: > Sean O'Halpin wrote: > >> On Thu, Mar 31, 2011 at 9:13 PM, Nick Dokos wrot= e: >> > Sean O'Halpin wrote: >> > >> >> On Wed, Mar 30, 2011 at 11:52 PM, Eric Schulte wrote: >> >> > Babel does have a way to bring changes back from pure source code i= nto >> >> > code blocks in an Org-mode document. =C2=A0While it isn't perfect (= especially >> >> > if you make extensive use of noweb references or variables) there a= re >> >> > mechanisms to maintain such a /sync/. =C2=A0To try this out, tangle= out code >> >> > with the ":comments yes" header argument, then change an element of= the >> >> > tangled source code, and use the `org-babel-detangle' function to b= ring >> >> > the changes back into the Org-mode document. >> >> > >> >> > Improving the detangling (or "illiterate") features is an area ripe= for >> >> > future Babel development. >> >> > > > ...example elided... > >> >>=20 >> >> which doesn't look right to me. >> >> >> > >> > What should it look like? >> > >> > Nick >> > >> To be honest, I don't know what it /should/ look like but I have >> ':comments yes' on three sections and get only one link on output, so >> I can't see how this would detangle properly. >>=20 >> Also, >>=20 >> # [[][main]] >>=20 >> is missing the file reference (in the first set of brackets), so it >> won't work as a link. >>=20 > > Yes, it does look unlikely. I don't know about the other comments (line > numbers, etc.) but at least the link calculation in > org-babel-tangle-collect-blocks is wrong I believe: it uses > org-store-link to supposedly store a link to the current location on the > global org-stored-links stack and then pops it, takes the car of it and > sanitizes text properties of the result: that then becomes the link that > should be stored in the tangled file. > > But it seems that org-store-link does not behave this way when called > non-interactively: I get nothing on the global stack. Instead it seems > to *return* the link as a string, which is then just thrown away. > This all looks to be correct, thanks for debugging this one. I've just pushed up a fix which brings the tangling link-extraction code up to date with the current version of org-store-link. The tangled comments should now appear as fully formed links. However, in testing this I noticed that the code for following these links form a source code file back into the original org-mode file (namely `org-babel-tangle-jump-to-org') is not currently working for some link types (e.g. id: links). The problem here is that there is no org function for parsing/following a link which can be called non-interactively. I'd like to either 1. change org-open-at-point (the function which currently holds all of the org-link following logic) so that it returns an object (probably the buffer, maybe the buffer and point) holding the information on the link target, so that other elisp code can follow org-mode links with something like. #+begin_src emacs-lisp (pop-to-buffer (org-open-link-at-point)) #+end_src =20=20=20 2. or, another option would be to pull the link-parsing logic out of org-open-link-at-point into a separate function which could then be called by org-open-link-at-point, and by other elisp functions wishing to use org-mode links. I'm not comfortable making either of these changes myself without Carsten or Bastien giving their OK. Best -- Eric