Comments break lists when exporting to TeX

Comments break lists when exporting to TeX

[Daniel Schoepe]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Hi,

while trying to include a source file in a list element via #+INCLUDE, I
discovered the following behavior: A comment between two list elements breaks
the list into two lists when exporting. For example:

* Test
  - This is a list element.
# This isn't.
  - This is another list element.

Becomes after exporting to .tex:

..
\begin{itemize}
\item This is a list element.
\end{itemize}
\begin{itemize}
\item This is another list element.
\end{itemize}
..

I think it makes sense for comments to have no effect on this (i.e. it
should behave the same during export as if it wasn't there), so I
consider this a bug.

This has the unfortunate side effect of no longer being able to include
a source file using #+INCLUDE while preserving its indentation in the
resulting PDF (as using #+BEGIN_SRC .. #+END_SRC would).

Cheers,
Daniel

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Comments break lists when exporting to TeX

[Nicolas Goaziou]

Hello,

Daniel Schoepe <daniel@schoepe.org> writes:

> while trying to include a source file in a list element via #+INCLUDE, I
> discovered the following behavior: A comment between two list elements breaks
> the list into two lists when exporting. For example:
>
> * Test
>   - This is a list element.
> # This isn't.
>   - This is another list element.

At the moment you insert text at column 0, the list ends.  You can use
inline comments (i.e. #+ This isn't) instead.

> I think it makes sense for comments to have no effect on this (i.e. it
> should behave the same during export as if it wasn't there), so I
> consider this a bug.

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.


Regards,

-- 
Nicolas Goaziou

Re: Comments break lists when exporting to TeX

[Daniel Schoepe]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Wed, 23.05.2012 14:21, Nicolas Goaziou wrote:
> At the moment you insert text at column 0, the list ends.  You can use
> inline comments (i.e. #+ This isn't) instead.

This however, does not solve my original problem, since it doesn't work
with #+INCLUDE (with version 7.8.09):

* 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

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

I think what I'm saying is that the comment shouldn't break up the lists
in the buffer either, but I don't have any strong feelings about this,
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).

Cheers,
Daniel

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Comments break lists when exporting to TeX

[Nicolas Goaziou]

Hello,

Daniel Schoepe <daniel@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