Re: new exporter: link abbrev

[Michael Brand <michael.ch.brand@gmail.com>]

Hi Nicolas

On Wed, Dec 5, 2012 at 10:05 PM, Nicolas Goaziou <n.goaziou@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