[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org pr

From: Nicolas Goaziou
Subject: Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Date: Sun, 01 Jun 2014 12:01:04 +0200

Achim Gratz <address@hidden> 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.


>>   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

> 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.

> <<"file.html">>

Again, I don't want to extend Org syntax, or only by a tiny part, hence
the two proposals above.


Nicolas Goaziou

reply via email to

[Prev in Thread] Current Thread [Next in Thread]