emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Myles English <mylesenglish@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [bug] [new-exporter] #+includes in non-exported regions do not work
Date: Mon, 29 Oct 2012 14:21:43 +0100	[thread overview]
Message-ID: <87boflquqg.fsf@gmail.com> (raw)
In-Reply-To: <87sj8xu0dj.fsf@ucl.ac.uk> (Eric S. Fraga's message of "Mon, 29 Oct 2012 08:51:36 +0000")

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

next prev parent reply	other threads:[~2012-10-29 13:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2012-10-29 20:19       ` Eric S Fraga
2012-10-29 21:42         ` Sebastien Vauban
2012-10-29 22:00           ` Nicolas Goaziou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87boflquqg.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mylesenglish@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).