From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [bug] [new-exporter] #+includes in non-exported regions do not work Date: Mon, 29 Oct 2012 14:21:43 +0100 Message-ID: <87boflquqg.fsf@gmail.com> References: <87mwz63mjx.fsf@ucl.ac.uk> <871ugi6dih.fsf@ed.ac.uk> <87sj8xu0dj.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSpKa-0003tM-4u for emacs-orgmode@gnu.org; Mon, 29 Oct 2012 09:24:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TSpKV-0001Oz-RL for emacs-orgmode@gnu.org; Mon, 29 Oct 2012 09:24:40 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:34531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSpKV-0001Ou-Kc for emacs-orgmode@gnu.org; Mon, 29 Oct 2012 09:24:35 -0400 Received: by mail-wi0-f169.google.com with SMTP id hq4so1824840wib.0 for ; Mon, 29 Oct 2012 06:24:34 -0700 (PDT) In-Reply-To: <87sj8xu0dj.fsf@ucl.ac.uk> (Eric S. Fraga's message of "Mon, 29 Oct 2012 08:51:36 +0000") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Myles English Cc: emacs-orgmode@gnu.org Hello, Eric S Fraga 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