From: KDr2 <killy.draw@gmail.com>
To: Org Mode List <emacs-orgmode@gnu.org>, mail@nicolasgoaziou.fr
Subject: Re: [ANN] Merge export-block type within special-block
Date: Fri, 29 Aug 2014 22:02:47 +0800 [thread overview]
Message-ID: <CAHfjm6hRE0SiqmQLQuSZcn3TyotC=HjLqoaWhHZTzWm=t-fazQ@mail.gmail.com> (raw)
In-Reply-To: <87y4vf0ygz.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
Hi Nicolas,
This is nice, but it brought 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 two footnotes in the generated HTML. Would you fix this please?
Thanks.
On Sun, Jul 27, 2014 at 8:37 PM, Nicolas Goaziou <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', 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
[-- Attachment #2: Type: text/html, Size: 4627 bytes --]
next prev parent reply other threads:[~2014-08-29 14:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-27 12:37 [ANN] Merge export-block type within special-block Nicolas Goaziou
2014-07-27 22:13 ` Bastien
2014-08-29 14:02 ` KDr2 [this message]
2014-08-31 12:56 ` Nicolas Goaziou
2014-09-25 15:12 ` KDr2
2014-09-26 9:09 ` Nicolas Goaziou
2014-09-28 6:18 ` Aaron Ecay
2014-09-28 7:26 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHfjm6hRE0SiqmQLQuSZcn3TyotC=HjLqoaWhHZTzWm=t-fazQ@mail.gmail.com' \
--to=killy.draw@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.