Re: [bug] [new-exporter] #+includes in non-exported regions do not work

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> 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
keywords expansion.

> 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.


Regards,

-- 
Nicolas Goaziou