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
