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

[Nicolas Goaziou]

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.

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