Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Hello, "Sebastien Vauban" writes: > Can we assume that `:noexport:' and `COMMENT' are complete synonyms, as of > today As of today, yes. > and will stay so in the foreseen future? I wouldn't bet. `:noexport' is /de facto/ limited to export. `COMMENT' keyword doesn't have to. Someone may come up with a broader use case. For example, it could prevent Babel blocks from being executed. Regards, -- Nicolas Goaziou
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Hi Nicolas and Eric, Eric S Fraga wrote: > 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. Can we assume that `:noexport:' and `COMMENT' are complete synonyms, as of today, and will stay so in the foreseen future? Best regards, Seb -- Sebastien Vauban
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Nicolas Goaziou writes: > Hello, > > Eric S Fraga 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
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Hello, Eric S Fraga 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
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Myles English writes: > Hi Eric, > > You have: > > #+include: uml.org > > I think it should be: > > #+include: "uml.org" Indeed it should be, or at least for the new exporter. Thanks for pointing this out. There is still a bug in that the exporter should fail more gracefully? 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. 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. Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.2.50.1 and Org release_7.9.2-406-g2c78ca-git
Re: [O] [bug] [new-exporter] #+includes in non-exported regions do not work
Hi Eric, You have: #+include: uml.org I think it should be: #+include: "uml.org" I have haven't tried it though. Myles Eric S Fraga writes: > Hello, > > with an up to date org, I cannot get the attached minimal example to > export using the new exporter. I have try exporting to latex-pdf, in > case that matters. The (line-length truncated) error trace is: > > --8<---cut here---start->8--- > Debugger entered--Lisp error: (wrong-type-argument stringp nil) > file-readable-p(nil) > (not (file-readable-p file)) > (cond ((not (file-readable-p file)) (error "Cannot include file %s" file)) > (let* ((value (match-string 1)) (ind (org-get-indentation)) (file (and (st > (progn (beginning-of-line) (let* ((value (match-string 1)) (ind (org-get-i > (if (eq (org-element-type (save-match-data (org-element-at-point))) (quote > (when (eq (org-element-type (save-match-data (org-element-at-point))) (quo > (while (re-search-forward "^[ ]*#\\+INCLUDE: \\(.*\\)" nil t) (whe > (let ((case-fold-search t)) (goto-char (point-min)) (while (re-search-forw > org-export-expand-include-keyword() > [...] > --8<---cut here---end--->8--- > > Note that the uml.org file referred to by the #+include exists. Also > note that the old exporter works. > > I am not entirely sure what the semantics for included files in the new > exporter are. For instance, is an include statement /within/ a > non-exported headline meant to be processed? > > Regardless, the fact that it fails to export is a bug, I guess. > > Thanks, > eric
[O] [bug] [new-exporter] #+includes in non-exported regions do not work
Hello, with an up to date org, I cannot get the attached minimal example to export using the new exporter. I have try exporting to latex-pdf, in case that matters. The (line-length truncated) error trace is: --8<---cut here---start->8--- Debugger entered--Lisp error: (wrong-type-argument stringp nil) file-readable-p(nil) (not (file-readable-p file)) (cond ((not (file-readable-p file)) (error "Cannot include file %s" file)) (let* ((value (match-string 1)) (ind (org-get-indentation)) (file (and (st (progn (beginning-of-line) (let* ((value (match-string 1)) (ind (org-get-i (if (eq (org-element-type (save-match-data (org-element-at-point))) (quote (when (eq (org-element-type (save-match-data (org-element-at-point))) (quo (while (re-search-forward "^[ ]*#\\+INCLUDE: \\(.*\\)" nil t) (whe (let ((case-fold-search t)) (goto-char (point-min)) (while (re-search-forw org-export-expand-include-keyword() [...] --8<---cut here---end--->8--- Note that the uml.org file referred to by the #+include exists. Also note that the old exporter works. I am not entirely sure what the semantics for included files in the new exporter are. For instance, is an include statement /within/ a non-exported headline meant to be processed? Regardless, the fact that it fails to export is a bug, I guess. Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.1.1 and Org release_7.9.2-516-g796fca # -*- org-confirm-babel-evaluate: nil; -*- #+TITLE: examplebug.org #+AUTHOR:Eric S Fraga #+EMAIL: e.fr...@ucl.ac.uk #+DATE: 2012-01-09 Mon #+EXPORT_EXCLUDE_TAGS: noexport * introduction This is some text that should be exported * conclusions :noexport: This is some text that will not be exported. It includes some text from another file. The presence of this include causes the new exporter to fail. #+include: uml.org
