From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Brand Subject: Re: new exporter: link abbrev Date: Thu, 6 Dec 2012 16:13:26 +0100 Message-ID: References: <87y5hctdk3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:34347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tgd8t-0004yb-Qr for emacs-orgmode@gnu.org; Thu, 06 Dec 2012 10:13:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tgd8i-0005wX-W0 for emacs-orgmode@gnu.org; Thu, 06 Dec 2012 10:13:39 -0500 Received: from mail-qa0-f48.google.com ([209.85.216.48]:62961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tgd8i-0005wR-RL for emacs-orgmode@gnu.org; Thu, 06 Dec 2012 10:13:28 -0500 Received: by mail-qa0-f48.google.com with SMTP id l8so791479qaq.0 for ; Thu, 06 Dec 2012 07:13:26 -0800 (PST) In-Reply-To: <87y5hctdk3.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Org Mode Hi Nicolas On Wed, Dec 5, 2012 at 10:05 PM, Nicolas Goaziou 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