emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [ANN] Merge export-block type within special-block


From: Aaron Ecay
Subject: Re: [O] [ANN] Merge export-block type within special-block
Date: Sun, 28 Sep 2014 02:18:22 -0400
User-agent: Notmuch/0.18.1+51~gbbbdf04 (http://notmuchmail.org) Emacs/24.4.50.2 (x86_64-unknown-linux-gnu)

Hi Nicolas,

I like the thrust of your initial patch very much; I would like to help
you make it happen.  Here’s some discussion as you requested in a
follow-up message.

2014ko abuztuak 31an, Nicolas Goaziou-ek idatzi zuen:
>
> Unfortunately, no, I cannot fix it.
> 
> The problem is even deeper. Indeed, my approach is fundamentally wrong:
> it is impossible to postpone choosing between parsed or raw data at
> export time. This information must be obtained at parsing time.
> 
> Yet, I think syntax should not depend on the libraries loaded. So the
> initial problem still needs a solution.
> 
> Special blocks and export blocks are just too similar.  We could make
> them slightly different. One solution is to mark explicitly blocks meant
> to insert raw code. E.g.,
> 
>   #+BEGIN_SOMETHING :special t
>   ...
>   #+END_SOMETHING
> 
> vs
> 
>   #+BEGIN_SOMETHING
>   ...
>   #+END_SOMETHING
>

I have a hunch that this is backwards.  It seems like the convention
has been to allow arbitrary special blocks in org files.  Sticking to
what I know best, these create arbitrarily-named environments in Latex.
Export blocks seem like the special case (e.g. the number of types is
constrained by the available export modules), and so they should have
to bear special marking.

What if you used the convention that all export blocks had the form
#+begin_export_latex, #+begin_export_html, etc.?  This should be
unambiguous to parse.  (It’s possible to bikeshed about the name, of
course: perhaps #+begin_literal_latex etc.)

HTH,

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]