Nicolas Goaziou <n.goaz...@gmail.com> writes: > 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.
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?). Okay. I can see that the new approach is more consistent and that is always a good thing in my books. I guess I was just perturbed at the change in behaviour, and mostly because the error message made no sense to me as the not-to-be-exported sections were all hidden in my view! [...] > 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. It's a problem only because of the way I use the :noexport: and COMMENT tags to exclude parts of a document that are often incomplete or partially defined. However, I do realise I am being inconsistent as I use :noexport: tags to hide babel code that is referenced in the rest of my documents often. There probably is really no problem at all; I just simply need to adjust to a more logical approach to incomplete sections, e.g. commenting out =#+= directives I do not want processed. This would include =INCLUDE= and =BEGIN_SRC=. Not a big deal. So, I don't think there is anything to be done. Thanks for listening and sorry for the noise! -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.2.50.1 and Org release_7.9.2-406-g2c78ca-git
