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.
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
next prev parent 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:
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=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 \
/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
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
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).