Hi Nicolas On Wed, Dec 5, 2012 at 10:05 PM, Nicolas Goaziou <n.goaz...@gmail.com> wrote: > The second one is a more difficult problem. Org Elements usually > translates links on the fly when parsing them: `org-element-link-parser' > calls `org-translate-link'. This function requires > `org-link-abbrev-alist' and `org-link-abbrev-alist-local' variables to > be set properly, the second one being a local variable. > > Unfortunately, parsing of secondary strings (in particular headline > titles or inline footnote definitions) happens in a temporary buffer, > where no local variable is set. There `org-link-abbrev-alist-local' is > nil, no matter what your #+LINK: keyword says, and link translation > can't happen. > > Also, local variables cannot be send to the temporary buffer, because > secondary string parsing can sometimes happen when the original buffer > isn't supposed to exist, that is during export (when the parse tree is > the only trusted data).
Thank you for the explanations. > A possible solution would be to move link translation from > org-element.el to org-export.el. But that would require to explicitly > call a translator function on links, which would be an additional task > for back-end developers. Also, `org-element-context' would not return > anymore the real path of the abbreviated link, only its raw path. I would like to not burden back-end developers with this. In the meantime I found out that I can simply add org-export-normalize-links to org-export-before-processing-hook and it seems to do what I expect. But this is probably not to be included in Org core because the (hopefully at least only basic) pre-parsing of org-export-normalize-links undermines the later parsing of org-elements. In case org-export-normalize-links would survive the old exporter (I fear it will not) the workaround of hooking would do it for me. Michael
