question about org-element-map missing link in caption

question about org-element-map missing link in caption

[John Kitchin]

In the following org document, org-element-map only finds one link, but
the buffer acts like there are two links. The free link is found, but
the link label buried in the caption is not found. However, it exports
correctly, and the caption link is clickable, so the buffer certainly
thinks it is a link. Is this expected behavior?

* test links

#+caption: some text label:test
| a | b |
| 1 | 3 |

label:test2

#+BEGIN_SRC emacs-lisp
(org-element-map (org-element-parse-buffer) 'link
      (lambda (link)
   (org-element-property :path link)))
#+END_SRC
#+RESULTS:
| test2 |



--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: question about org-element-map missing link in caption

[Nicolas Goaziou]

Hello,

John Kitchin <johnrkitchin@gmail.com> writes:

> In the following org document, org-element-map only finds one link, but
> the buffer acts like there are two links. The free link is found, but
> the link label buried in the caption is not found. However, it exports
> correctly, and the caption link is clickable, so the buffer certainly
> thinks it is a link. Is this expected behavior?

It is. By default, `org-element-map' doesn't look into captions. See
WITH-AFFILIATED optional argument.


Regards,

-- 
Nicolas Goaziou

Re: question about org-element-map missing link in caption

[John Kitchin]

Thanks that is what I needed!

I tried it, and indeed the links in captions are found, but something is
still not right. The :begin properties of the links in the caption seem
to be relative to the point after the : in the caption. That isn't
obvious and makes it hard to store a marker to the link. Is that
expected behavior?

* test links

#+caption: some text label:test3  cite:needs-1989-cal
| a | b |
| 1 | 3 |

 citenum:needs-1989-calcu

#+BEGIN_SRC emacs-lisp :results code
(org-element-map (org-element-parse-buffer) 'link
  (lambda (link)
    (cons
     (org-element-property :path link)
     (org-element-property :begin link)))
  nil nil nil t)
#+END_SRC
#+RESULTS:
#+BEGIN_SRC emacs-lisp
(("test3" . 11)
 ("needs-1989-cal" . 24)
 ("needs-1989-calcu" . 91))
#+END_SRC

(goto-char 11) This goes into the headline

(goto-char 24) This goes to the : in the caption

(goto-char 91)  This goes exactly where I expect


Nicolas Goaziou writes:

> Hello,
>
> John Kitchin <johnrkitchin@gmail.com> writes:
>
>> In the following org document, org-element-map only finds one link, but
>> the buffer acts like there are two links. The free link is found, but
>> the link label buried in the caption is not found. However, it exports
>> correctly, and the caption link is clickable, so the buffer certainly
>> thinks it is a link. Is this expected behavior?
>
> It is. By default, `org-element-map' doesn't look into captions. See
> WITH-AFFILIATED optional argument.
>
>
> Regards,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: question about org-element-map missing link in caption

[Nicolas Goaziou]

John Kitchin <johnrkitchin@gmail.com> writes:

> I tried it, and indeed the links in captions are found, but something is
> still not right. The :begin properties of the links in the caption seem
> to be relative to the point after the : in the caption. That isn't
> obvious and makes it hard to store a marker to the link. Is that
> expected behavior?

This is an implementation detail. Parsing for secondary strings (e.g.,
captions, some keywords like "TITLE") happens in a temporary buffer. You
cannot trust buffer positions in this case.


Regards,

Re: question about org-element-map missing link in caption

[John Kitchin]

hmm... Is there any way to tell when a link in in an affiliate? so we
can tell when we cannot trust buffer positions?

Maybe even better fix the implementation to add the found buffer
positions to some affiliate position so they are correct? I could give
that a try if you can point me to the function it occurs in.

Thanks.


Nicolas Goaziou writes:

> John Kitchin <johnrkitchin@gmail.com> writes:
>
>> I tried it, and indeed the links in captions are found, but something is
>> still not right. The :begin properties of the links in the caption seem
>> to be relative to the point after the : in the caption. That isn't
>> obvious and makes it hard to store a marker to the link. Is that
>> expected behavior?
>
> This is an implementation detail. Parsing for secondary strings (e.g.,
> captions, some keywords like "TITLE") happens in a temporary buffer. You
> cannot trust buffer positions in this case.
>
>
> Regards,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: question about org-element-map missing link in caption

[Nicolas Goaziou]

John Kitchin <johnrkitchin@gmail.com> writes:

> hmm... Is there any way to tell when a link in in an affiliate? so we
> can tell when we cannot trust buffer positions?

There is `org-element-secondary-p'.

> Maybe even better fix the implementation to add the found buffer
> positions to some affiliate position so they are correct?

This is not always possible: some strings are parsed when the original
buffer is not available anymore (this happens often during export).

However, it is possible to fix it for captions. I did it in master.


Regards,

Re: question about org-element-map missing link in caption

[John Kitchin]

Thanks. It looks like `org-element-secondary-p' is upstream of my org version
(8.2.10) but I look forward to seeing it work in the future!

BTW, the application of this is in checking cite/ref/label links for
correctness in org-buffers. It is not uncommon to have these in
figure/table captions. I was mapping over all of them and collecting the
positions to make a clickable buffer to go straight to the bad links
(e.g the ones with no bibtex entries, or that ref a non-existent label,
or that have multiply defined labels). It is pretty amazing what is
possible with this machinery!

Best wishes,

Nicolas Goaziou writes:

> John Kitchin <johnrkitchin@gmail.com> writes:
>
>> hmm... Is there any way to tell when a link in in an affiliate? so we
>> can tell when we cannot trust buffer positions?
>
> There is `org-element-secondary-p'.
>
>> Maybe even better fix the implementation to add the found buffer
>> positions to some affiliate position so they are correct?
>
> This is not always possible: some strings are parsed when the original
> buffer is not available anymore (this happens often during export).
>
> However, it is possible to fix it for captions. I did it in master.
>
>
> Regards,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu