From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aaron Ecay <aaronecay@gmail.com>
Subject: Re: [ANN] Merge export-block type within special-block
Date: Sun, 28 Sep 2014 02:18:22 -0400
Message-ID: <87r3ywl13l.fsf@gmail.com>
References: <87y4vf0ygz.fsf@nicolasgoaziou.fr>
	<CAHfjm6hRE0SiqmQLQuSZcn3TyotC=HjLqoaWhHZTzWm=t-fazQ@mail.gmail.com>
	<87oav0vmv1.fsf@nicolasgoaziou.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44551)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1XY7om-0004PP-Ow
	for emacs-orgmode@gnu.org; Sun, 28 Sep 2014 02:18:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1XY7od-0006Il-Mg
	for emacs-orgmode@gnu.org; Sun, 28 Sep 2014 02:18:48 -0400
In-Reply-To: <87oav0vmv1.fsf@nicolasgoaziou.fr>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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 <mail@nicolasgoaziou.fr>, KDr2 <killy.draw@gmail.com>
Cc: Bastien Guerry <bzg@gnu.org>, Org Mode List <emacs-orgmode@gnu.org>

Hi Nicolas,

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

2014ko abuztuak 31an, Nicolas Goaziou-ek idatzi zuen:
>
> Unfortunately, no, I cannot fix it.
>=20
> 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.
>=20
> Yet, I think syntax should not depend on the libraries loaded. So the
> initial problem still needs a solution.
>=20
> 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.,
>=20
>   #+BEGIN_SOMETHING :special t
>   ...
>   #+END_SOMETHING
>=20
> vs
>=20
>   #+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=E2=80=99s possible to bikeshed about the name, of
course: perhaps #+begin_literal_latex etc.)

HTH,

--=20
Aaron Ecay