Hello, Daniel Schoepe <dan...@schoepe.org> writes:
> * Test > - This will not indent the code properly as a part of the list element > #+INCLUDE foo.c src c > - This will print "#+INCLUDE .." literally: > #+INCLUDE foo.c src c > - This works as expected: > #+BEGIN_SRC c > <contents of foo.c> > #+END_SRC This should be "#+INCLUDE: "foo.c" src c", not "#+INCLUDE foo.c src c" > Of course I could fall back to something like \lstlistinginput, but that > works only for TeX-export and hence defeats the whole point of > result-format-agnostic directives such as #+INCLUDE (at least when it's > used for source files). > >> I do not. Export is consistent with in-buffer behaviour. You have >> created two lists here, not one, and it has nothing to do with export. > > I find it odd for a comment to have such an effect on the "semantics" > of the document. My intuition about comments (that aren't special > directives) is that they have no effect on the final result (the PDF > in this case, or the binary in the case of compilable source code). Note that INCLUDE keyword isn't a comment. Also, again, comments have no effect on the final result: they are consistent with what happens within buffer. [...] > as long I can get #+INCLUDE to work in list elements. (But it would be a > nice, general rule that would allow #+INCLUDE to work as "expected". > Another alternative would be to make all such directives also work when > they're not at column 0). --8<---------------cut here---------------start------------->8--- - This will print "#+INCLUDE .." literally: #+INCLUDE: "foo.c" src c --8<---------------cut here---------------end--------------->8--- This works as expected in the new exporter. Regards, -- Nicolas Goaziou
