>>> #+results: is-converted-to-listings
>>> #+begin_example
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> #+end_example
>>>
>>> gets translated (in LaTeX) to:
>>>
>>> #+begin_src latex
>>> \begin{lstlisting}
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> autoload
>>> \end{lstlisting}
>>> #+end_src
>>>
>>> ** Short output
>>>
>>> ... while
>>>
>>> #+srcname: is-converted-to-verbatim
>>> #+begin_src sh :results output :exports both
>>> grep autoload ~/Downloads/emacs/site-lisp/org-mode/lisp/ob.el | cut -d "#"
>>> -f 4 | head -n 3
>>> #+end_src
>>>
>>> #+results: is-converted-to-verbatim
>>> : autoload
>>> : autoload
>>> : autoload
>>>
>>> gets translated (in LaTeX) to:
>>>
>>> #+begin_src latex
>>> \begin{verbatim}
>>> autoload
>>> autoload
>>> autoload
>>> \end{verbatim}
>>> #+end_src
>>>
>>> with a leading space (that you don't see when running the command in the
>>> shell).
>>>
> 2. What's the determining factor for switching between =verbatim= and
>>> =lstlisting= environments?
>>
>> I'm no expert on latex export. But if the colon form and the block form are
>> equivalent in Org,
>
> OK... In a way, you confirm my point of view, considering that both are
> equivalent in Org...
>
>
>> then perhaps it is a bug that they have non-equivalent latex export?
>
> Exactly what I'm thinking...
>
>
>> I didn't realise that begin_example resulted in a lstlisting environment
>> when using listings with Org.
>
> My only custom (AFAIK) is:
>
> ;; tell org to use listings (instead of verbatim) for source code
> (setq org-export-latex-listings t)
>
> ;; if you want fontified source code, then you must include the
> ;; `listings' package
> (add-to-list 'org-export-latex-packages-alist '("" "listings") t)
>
> ;; if you want colored source code, then you need to include the
> ;; `xcolor' package
> (add-to-list 'org-export-latex-packages-alist '("" "xcolor") t)
>
>
>>> 3. Why is there a leading space in the =verbatim= environment?
>>
>> I guess it is due to the space after the colon in the Org buffer.
>
> I find it nice (not to say necessary) to have a space after the colon in the
> Org buffer.
>
> But, when exporting, as both have been added as a prefix in front of every
> result line, both should be removed, ensuring no extra space in the LaTeX
> output...
OK, I think the conclusion of this that
1. It does not reveal a bug in babel.
2. There may be a bug in the listings export code in that it fails to
recognise colons as a verbatim environment
3. There may be a second bug in the vanilla latex export code in that it
should remove the space which follows the protective colon.
Dan
>
> Thanks for your answer.
>
> Best regards,
> Seb
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
