From mboxrd@z Thu Jan 1 00:00:00 1970 From: KDr2 Subject: Re: [ANN] Merge export-block type within special-block Date: Fri, 29 Aug 2014 22:02:47 +0800 Message-ID: References: <87y4vf0ygz.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0115fca2dd942b0501c51c39 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNMlj-0002Tg-2Y for emacs-orgmode@gnu.org; Fri, 29 Aug 2014 10:03:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNMlh-0005Rw-Ah for emacs-orgmode@gnu.org; Fri, 29 Aug 2014 10:03:11 -0400 Received: from mail-ob0-x234.google.com ([2607:f8b0:4003:c01::234]:33184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNMlh-0005RS-3O for emacs-orgmode@gnu.org; Fri, 29 Aug 2014 10:03:09 -0400 Received: by mail-ob0-f180.google.com with SMTP id m8so1803938obr.39 for ; Fri, 29 Aug 2014 07:03:08 -0700 (PDT) In-Reply-To: <87y4vf0ygz.fsf@nicolasgoaziou.fr> 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 , mail@nicolasgoaziou.fr --089e0115fca2dd942b0501c51c39 Content-Type: text/plain; charset=UTF-8 Hi Nicolas, This is nice, but it brought a bug, `[N]' in HTML block is recognized as footnote, e.g.: #+BEGIN_HTML ONE[1] #+END_HTML There are two footnotes in the generated HTML. Would you fix this please? Thanks. On Sun, Jul 27, 2014 at 8:37 PM, Nicolas Goaziou wrote: > 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 > > -- -- KDr2, http://kdr2.com --089e0115fca2dd942b0501c51c39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Nicolas,

This is nice, but it brou= ght a bug, `[N]' in HTML block is recognized as footnote, e.g.:

= #+BEGIN_HTML
ONE[1]
<script>
console.log(v1= [0]);
</script>
#+END_HTML

There are t= wo footnotes in the generated HTML. Would you fix this please?

Than= ks.




On Sun, Jul 27, 2014 at 8:37 PM, Nicolas Goa= ziou <mail@nicolasgoaziou.fr> wrote:
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', s= o
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.,

=C2=A0 #+BEGIN_HTML
=C2=A0 ...
=C2=A0 #+END_HTML

will be parsed as a `special-block' if "ox-html.el" is not lo= aded, or an
`export-block' otherwise. This is slightly... ugly. And it gets worse i= f
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 s= o
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&#= 39;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 n= ot
related to Org syntax.

This is more simple to handle than it sounds, and can be described with
two steps:

=C2=A0 1. `export-block' elements, translators and filters are now igno= red.
=C2=A0 =C2=A0 =C2=A0These can be removed from export back-ends (unless you = want to
=C2=A0 =C2=A0 =C2=A0preserve compatibility with Org 8.2, in which case leav= ing them
=C2=A0 =C2=A0 =C2=A0will not hurt: they will be used in Org 8.2 and ignored= in Org
=C2=A0 =C2=A0 =C2=A08.3).

=C2=A0 2. Translators for special blocks, e.g. `org-BACKEND-special-block&#= 39;
=C2=A0 =C2=A0 =C2=A0need to be updated and check first if current block is = a raw
=C2=A0 =C2=A0 =C2=A0special block or not. The following template is a sugge= stion.

=C2=A0 =C2=A0 =C2=A0#+BEGIN_SRC emacs-lisp
=C2=A0 =C2=A0 =C2=A0(defun org-latex-special-block (special-block contents = info)
=C2=A0 =C2=A0 =C2=A0 =C2=A0(if (org-export-raw-special-block-p special-bloc= k info)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(org-element-property :raw-value s= pecial-block)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Usual handling for special blocks goes= here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0))
=C2=A0 =C2=A0 =C2=A0#+END_SRC

=C2=A0 =C2=A0 =C2=A0Note that if BACKEND is a derived back-end and doesn= 9;t implement
=C2=A0 =C2=A0 =C2=A0its own special block translator already, there is noth= ing to
=C2=A0 =C2=A0 =C2=A0change. The parent back-end will take care of such bloc= ks.

=C2=A0 =C2=A0 =C2=A0All back-ends in core and in contrib have been updated = this way
=C2=A0 =C2=A0 =C2=A0already.

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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x80A93738




--
--=C2=A0
--089e0115fca2dd942b0501c51c39--