emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Illiterate programming question


From: Eric Schulte
Subject: Re: [O] Illiterate programming question
Date: Fri, 01 Apr 2011 10:41:11 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Nick Dokos <address@hidden> writes:

> Sean O'Halpin <address@hidden> wrote:
>
>> On Thu, Mar 31, 2011 at 9:13 PM, Nick Dokos <address@hidden> wrote:
>> > Sean O'Halpin <address@hidden> wrote:
>> >
>> >> On Wed, Mar 30, 2011 at 11:52 PM, Eric Schulte <address@hidden> wrote:
>> >> > Babel does have a way to bring changes back from pure source code into
>> >> > code blocks in an Org-mode document.  While it isn't perfect (especially
>> >> > if you make extensive use of noweb references or variables) there are
>> >> > mechanisms to maintain such a /sync/.  To 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 bring
>> >> > the changes back into the Org-mode document.
>> >> >
>> >> > Improving the detangling (or "illiterate") features is an area ripe for
>> >> > future Babel development.
>> >> >
>
> ...example elided...
>
>> >> 
>> >> 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.
>> 
>> Also,
>> 
>>     # [[][main]]
>> 
>> is missing the file reference (in the first set of brackets), so it
>> won't work as a link.
>> 
>
> 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
   
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]