[O] Re: Illiterate programming question

[Sébastien Vauban]

Hi Eric,

"Eric Schulte" wrote:
> 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:
>>> >> which doesn't look right to me.
>>>
>>> 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.

For sure, this is a regression between somewhere around Wed Mar 23 2011 (can
be a couple of days before, would I have passed days without updating Org --
that can't be true?) and now...

--8<---------------cut here---------------start------------->8---
diff --git a/org/css/worg-leuven.css b/org/css/worg-leuven.css
index 0706bc2..970aa78 100755
--- a/org/css/worg-leuven.css
+++ b/org/css/worg-leuven.css
@@ -1,11 +1,11 @@
 
-/* [[id:a69e0323-2643-418b-bf1a-75c7dc53cf74][External-CSS:1]] */
+/* [[][External-CSS:1]] */
--8<---------------cut here---------------end--------------->8---

As you can see, I *had* correct ID comments the last time I tangled the CSS
file. Now, not anymore, with user changes (AFAICT).

Best regards,
  Seb

-- 
Sébastien Vauban