Hello, Eric S Fraga <e.fr...@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
