From mboxrd@z Thu Jan 1 00:00:00 1970 From: Omid Subject: Re: #+INCLUDE: myfile.html html does not include /literally/; Org processes Date: Sun, 01 Jun 2014 06:01:29 -0400 Message-ID: <538AF9F9.3000004@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; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr2aF-0006oA-Q7 for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 06:01:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wr2a4-0008Ca-I5 for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 06:01:43 -0400 Received: from mail-yh0-x22a.google.com ([2607:f8b0:4002:c01::22a]:54369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr2a4-0008CU-Ee for emacs-orgmode@gnu.org; Sun, 01 Jun 2014 06:01:32 -0400 Received: by mail-yh0-f42.google.com with SMTP id t59so2977865yho.15 for ; Sun, 01 Jun 2014 03:01:32 -0700 (PDT) Received: from [10.0.0.2] (host-207-254.fltavth.clients.pavlovmedia.com. [68.234.207.254]) by mx.google.com with ESMTPSA id z67sm15033233yhk.50.2014.06.01.03.01.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 03:01:31 -0700 (PDT) In-Reply-To: <87wqd1yo84.fsf@Rainer.invalid> 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: emacs-orgmode@gnu.org Thank you for the patch, Achim. On 06/01/2014 05:26 AM, Achim Gratz wrote: > Nicolas Goaziou writes: >> Thanks for the patch. However, I'd rather not allow arbitrary blocks >> around included files, as it can be the source of some headache (e.g., >> a quote block around an Org file containing a headline). Also we don't >> really need it since most use-cases are already supported. > > Fair enough. FWIW, I'm pretty sure the problem of the OP can also be > solved with Babel, perhaps even with an inline function, but I haven't > yet tried and it's likely to be quite a bit less intuitive than using > INCLUDE. > >> 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. > >> 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? 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. Here are two more options with different degrees of iffyness: > > #+INCLUDE_HTML: "file.html" > > #+BEGIN_HTML > <<"file.html">> > #+END_HTML > I think #+INCLUDE: should be just that: Include whatever the user is asking to. No header arguments dumps the file in Org (as it does now), subject to the usual processing, and a header argument like html wraps it in the appropriate delimiter, subject to processing according to that delimiter. I is up to the user to make sure the included content doesn't break things or lead to unexpected behavior. This functionality will be an extension of C's #include (the extension being the addition of delimiters around the included content if the user asks that) and in that sense I think it would be most appropriate. > > Regards, > Achim. > Regards, Omid Sent from my Emacs