* [bug] [new-exporter] #+includes in non-exported regions do not work
@ 2012-10-28 10:42 Eric S Fraga
2012-10-28 11:29 ` Myles English
0 siblings, 1 reply; 7+ messages in thread
From: Eric S Fraga @ 2012-10-28 10:42 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: examplebug.org --]
[-- Type: text/orgmode, Size: 452 bytes --]
# -*- org-confirm-babel-evaluate: nil; -*-
#+TITLE: examplebug.org
#+AUTHOR: Eric S Fraga
#+EMAIL: e.fraga@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug] [new-exporter] #+includes in non-exported regions do not work
2012-10-28 10:42 [bug] [new-exporter] #+includes in non-exported regions do not work Eric S Fraga
@ 2012-10-28 11:29 ` Myles English
2012-10-29 8:51 ` Eric S Fraga
0 siblings, 1 reply; 7+ messages in thread
From: Myles English @ 2012-10-28 11:29 UTC (permalink / raw)
To: Eric S Fraga; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug] [new-exporter] #+includes in non-exported regions do not work
2012-10-28 11:29 ` Myles English
@ 2012-10-29 8:51 ` Eric S Fraga
2012-10-29 13:21 ` Nicolas Goaziou
0 siblings, 1 reply; 7+ messages in thread
From: Eric S Fraga @ 2012-10-29 8:51 UTC (permalink / raw)
To: Myles English; +Cc: emacs-orgmode
Myles English <mylesenglish@gmail.com> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug] [new-exporter] #+includes in non-exported regions do not work
2012-10-29 8:51 ` Eric S Fraga
@ 2012-10-29 13:21 ` Nicolas Goaziou
2012-10-29 20:19 ` Eric S Fraga
0 siblings, 1 reply; 7+ messages in thread
From: Nicolas Goaziou @ 2012-10-29 13:21 UTC (permalink / raw)
To: Myles English; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug] [new-exporter] #+includes in non-exported regions do not work
2012-10-29 13:21 ` Nicolas Goaziou
@ 2012-10-29 20:19 ` Eric S Fraga
2012-10-29 21:42 ` Sebastien Vauban
0 siblings, 1 reply; 7+ messages in thread
From: Eric S Fraga @ 2012-10-29 20:19 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Myles English, emacs-orgmode
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> 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.
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug] [new-exporter] #+includes in non-exported regions do not work
2012-10-29 20:19 ` Eric S Fraga
@ 2012-10-29 21:42 ` Sebastien Vauban
2012-10-29 22:00 ` Nicolas Goaziou
0 siblings, 1 reply; 7+ messages in thread
From: Sebastien Vauban @ 2012-10-29 21:42 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug] [new-exporter] #+includes in non-exported regions do not work
2012-10-29 21:42 ` Sebastien Vauban
@ 2012-10-29 22:00 ` Nicolas Goaziou
0 siblings, 0 replies; 7+ messages in thread
From: Nicolas Goaziou @ 2012-10-29 22:00 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
Hello,
"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-10-29 22:03 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-28 10:42 [bug] [new-exporter] #+includes in non-exported regions do not work Eric S Fraga
2012-10-28 11:29 ` Myles English
2012-10-29 8:51 ` Eric S Fraga
2012-10-29 13:21 ` Nicolas Goaziou
2012-10-29 20:19 ` Eric S Fraga
2012-10-29 21:42 ` Sebastien Vauban
2012-10-29 22:00 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).