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 12:01:04 +0200 Message-ID: <8738fpeyov.fsf@gmail.com> References: <538AA6B8.40604@gmail.com> <8761kl12w9.fsf@Rainer.invalid> <87bnudf2u4.fsf@gmail.com> <87wqd1yo84.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr2Z6-0005Ne-N6 for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 06:00:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wr2Z1-0007tQ-E5 for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 06:00:32 -0400 Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:49769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr2Z1-0007tA-63 for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 06:00:27 -0400 Received: by mail-we0-f179.google.com with SMTP id q59so3915688wes.10 for ; Sun, 01 Jun 2014 03:00:25 -0700 (PDT) In-Reply-To: <87wqd1yo84.fsf@Rainer.invalid> (Achim Gratz's message of "Sun, 01 Jun 2014 11:26:51 +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: > Nicolas Goaziou writes: >> Actually, I think there are two possible ways to handle this: >> >> 1. Add a new "export" (or something else) parameter which will wrap >> file contents within an export block relative to the current >> back-end. Unfortunately, this will not work for exotic back-ends >> that do not provide such a block (:export-block property in its >> definition). We can always fallback to an example block in this >> case, though. > > Please not. Why? >> 2. Extend "src" syntax to allow Babel parameters after the language. >> E.g., >> >> #+INCLUDE: "file.html" src html :results html > > That looks better, but still isn't quite self-explanatory. What > happens if I write > > #+INCLUDE: "file.html" src html :results elisp > > for instance? The same as if you write #+INCLUDE: "file.html" src html but with an additional :results elisp Babel parameter, whatever it may mean. > That would still wrap the include file with an almost arbitrary block, > no? > I don't think you can check that the file to be included fulfills > all the requirements of being included at that point anyway. We don't need to. I didn't like the "wrap" parameter because it mixes parsed blocks (e.g., wrap quote) and raw blocks (e.g., wrap html). It is important to know if the parser should parse the contents of the file or not. Therefore, the new syntax, if any, should make it clear. In the current problem, we mustn't parse the contents of the file. > Here are two more options with different degrees of iffyness: > > #+INCLUDE_HTML: "file.html" This would extend Org syntax, by a large part. This is not necessary for the problem at hand. > #+BEGIN_HTML > <<"file.html">> > #+END_HTML Again, I don't want to extend Org syntax, or only by a tiny part, hence the two proposals above. Regards, -- Nicolas Goaziou