From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes Date: Sun, 01 Jun 2014 16:00:30 +0200 Message-ID: <87fvjoenlt.fsf@gmail.com> References: <538AA6B8.40604@gmail.com> <8761kl12w9.fsf@Rainer.invalid> <87bnudf2u4.fsf@gmail.com> <87wqd1yo84.fsf@Rainer.invalid> <8738fpeyov.fsf@gmail.com> <87sinpylly.fsf@Rainer.invalid> <87r438eujq.fsf@gmail.com> <87iookzsto.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr6Io-0001pZ-Mc for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 10:00:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wr6Ij-0007sv-Es for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 09:59:58 -0400 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:62675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr6Ij-0007sj-7n for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 09:59:53 -0400 Received: by mail-we0-f170.google.com with SMTP id u57so4077704wes.15 for ; Sun, 01 Jun 2014 06:59:52 -0700 (PDT) In-Reply-To: <87iookzsto.fsf@Rainer.invalid> (Achim Gratz's message of "Sun, 01 Jun 2014 15:02:11 +0200") 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: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz writes: > I'm still not getting your argument or I misunderstand what you're > trying to say. Using "wrap" should produce an export block and nothing > else. So as long as there can be no export block named "center", the > INCLUDE above would simply raise a user-error (yes, that check isn't in > the quick&dirty patch I posted). I thought you wanted to be able to wrap the contents within any block. If you limit it to export blocks, then we're suggesting the same idea. However, note that "wrap" is confusing because it sounds like Babel's keyword and yet does something different. > And since I think the list of NAMES that fit this description and is > known in advance (by org syntax) ... Unfortunately, that assumption is slightly wrong. Export blocks are defined by export back-ends. If the export back-end is not loaded, the block is a special block. This is not great, but in practice, it doesn't matter much as we can safely assume all used back-ends are required already at the time of export. The only export block we know for sure is the one defined in the current back-end, hence my initial proposal. Of course, it is still possible to raise a user-error (e.g., "unknown export block") in front of anything unknown at the time of export. Regards, -- Nicolas Goaziou