From: Nicolas Goaziou <firstname.lastname@example.org>
To: Myles English <email@example.com>
Subject: Re: [bug] [new-exporter] #+includes in non-exported regions do not work
Date: Mon, 29 Oct 2012 14:21:43 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Eric S. Fraga's message of "Mon, 29 Oct 2012 08:51:36 +0000")
Eric S Fraga <firstname.lastname@example.org> writes:
> There is still a bug in that the exporter should fail more gracefully?
Agreed. This syntax error should be more explicit now. Thanks.
> The question of structural interpretation remains: should the file be
> included if it is found within a not-to-be-exported headline? This is,
> at least for me, unexpected behaviour based on previous experience with
> the old exporter.
There's a design choice at the roots of the export engine development:
External parts (i.e. everything but org-export.el and back-ends)
shouldn't have to know anything about the exporter (much like the Fight
club, isn't it?).
Note that this isn't the case with current exporter (org-exp.el): many
files, including org-list.el, org-footnote.el... have to cope with
org-exp's internals (i.e. text properties encountered only during
export) so everything can run (almost) smoothly.
By that design choice, Babel blocks execution should happen
independently on export context, like exclude tags. And, by another
principle, the one of least surprise, the same happens for include
> Now, from C programming and so on, the behaviour in
> the new exporter is reasonable; however, as there is no way to
> optionally included material from another file, I prefer the behaviour
> of the old exporter.
I like the current behaviour. I also fail to see why it should be
a problem. Though, I'm open to discussion to implement a mid-way
solution. Maybe with the COMMENT keyword which is exporter agnostic.
next prev parent reply other threads:[~2012-10-29 13:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-28 10:42 [bug] [new-exporter] #+includes in non-exported regions do not work Eric S Fraga
2012-10-28 11:29 ` Myles English
2012-10-29 8:51 ` Eric S Fraga
2012-10-29 13:21 ` Nicolas Goaziou [this message]
2012-10-29 20:19 ` Eric S Fraga
2012-10-29 21:42 ` Sebastien Vauban
2012-10-29 22:00 ` Nicolas Goaziou
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).