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

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

[Eric S Fraga]

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

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

[Myles English]

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

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

[Eric S Fraga]

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

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

[Nicolas Goaziou]

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

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

[Eric S Fraga]

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

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

[Sebastien Vauban]

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: [bug] [new-exporter] #+includes in non-exported regions do not work

[Nicolas Goaziou]

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