From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: [ANN] Merge export-block type within special-block Date: Sun, 27 Jul 2014 14:37:16 +0200 Message-ID: <87y4vf0ygz.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBNgz-0006kh-3t for emacs-orgmode@gnu.org; Sun, 27 Jul 2014 08:36:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBNgo-0006le-Ts for emacs-orgmode@gnu.org; Sun, 27 Jul 2014 08:36:45 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:51198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBNgo-0006la-Kk for emacs-orgmode@gnu.org; Sun, 27 Jul 2014 08:36:34 -0400 Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id C594FA80B6 for ; Sun, 27 Jul 2014 14:36:32 +0200 (CEST) Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id vZzNoGQscWVU for ; Sun, 27 Jul 2014 14:36:31 +0200 (CEST) Received: from selenimh (unknown [91.224.148.150]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 557ABA80B1 for ; Sun, 27 Jul 2014 14:36:31 +0200 (CEST) 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: Org Mode List Hello, Export blocks are blocks dedicated to export back-ends, e.g., "#+BEGIN_LATEX". The way they are currently parsed is flawed. Export blocks are back-end dependent. At the moment, back-ends register their own export block in a variable, `org-element-block-name-alist', so the parser can know if it needs to parse an export block or not. As a consequence, the same block can be parsed differently if a given export back-end is loaded or not. E.g., #+BEGIN_HTML ... #+END_HTML will be parsed as a `special-block' if "ox-html.el" is not loaded, or an `export-block' otherwise. This is slightly... ugly. And it gets worse if we include the cache, which will not update the block if it is not modified. I just committed a set of patches that solve the problem: `export-block' elements do not exist anymore. Instead, such blocks are now parsed as `special-block', always. This does not depend on the libraries loaded so far. Of course, special blocks are not treated exactly as export blocks. The latter's contents are included as-is in the output whereas the former's are interpreted. Therefore, special blocks now include another property, :raw-value, which stores the pristine initial contents of the block, and "ox.el" provides a new function, `org-export-raw-special-block-p', which tells the difference between a former export block and a special block. This makes sense since an "export-block" is clearly, and only, an export concept. This is not related to Org syntax. This is more simple to handle than it sounds, and can be described with two steps: 1. `export-block' elements, translators and filters are now ignored. These can be removed from export back-ends (unless you want to preserve compatibility with Org 8.2, in which case leaving them will not hurt: they will be used in Org 8.2 and ignored in Org 8.3). 2. Translators for special blocks, e.g. `org-BACKEND-special-block' need to be updated and check first if current block is a raw special block or not. The following template is a suggestion. #+BEGIN_SRC emacs-lisp (defun org-latex-special-block (special-block contents info) (if (org-export-raw-special-block-p special-block info) (org-element-property :raw-value special-block) ;; Usual handling for special blocks goes here. )) #+END_SRC Note that if BACKEND is a derived back-end and doesn't implement its own special block translator already, there is nothing to change. The parent back-end will take care of such blocks. All back-ends in core and in contrib have been updated this way already. I included `org-export-raw-special-block-p' in Org 8.2, as a forward-compatibility measure, so back-end maintainers do not have to do the `fboundp' dance. BTW, for those in the back of the room: I didn't remove "#+BEGIN_LATEX"-like constructs. Regards, -- Nicolas Goaziou 0x80A93738