emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric S Fraga <e.fraga@ucl.ac.uk>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Myles English <mylesenglish@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [bug] [new-exporter] #+includes in non-exported regions do not work
Date: Mon, 29 Oct 2012 20:19:32 +0000	[thread overview]
Message-ID: <871ugh58vf.fsf@ucl.ac.uk> (raw)
In-Reply-To: <87boflquqg.fsf@gmail.com> (Nicolas Goaziou's message of "Mon, 29 Oct 2012 14:21:43 +0100")

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.


>> 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 and Org release_7.9.2-406-g2c78ca-git

  reply	other threads:[~2012-10-29 20:58 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
2012-10-29 20:19       ` Eric S Fraga [this message]
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:

  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=871ugh58vf.fsf@ucl.ac.uk \
    --to=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=mylesenglish@gmail.com \
    --cc=n.goaziou@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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