[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not w
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Mon, 29 Oct 2012 14:21:43 +0100
Eric S Fraga <address@hidden> 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.