Re: [Org-Babel] Export environments for shell results?

From: "Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: [Org-Babel] Export environments for shell results?
Date: Thu, 07 Oct 2010 15:35:40 +0200	[thread overview]
Message-ID: <8739sidt1v.fsf@mundaneum.com> (raw)
In-Reply-To: 87y6abwdf7.fsf@stats.ox.ac.uk

Hi Dan,

Dan Davison wrote:
> Sébastien Vauban writes:
>> #+TITLE: Org-Babel export environments for shell results
>>
>> * Example
>>
>> ** Medium output
>>
>> #+srcname: is-converted-to-listings
>> #+begin_src sh :results output :exports both
>> grep autoload ~/Downloads/emacs/site-lisp/org-mode/lisp/ob.el | cut -d "#" -f 4
>> #+end_src
>
> (It's nice that your email is in Org format; I can get the contents into an
> Org buffer quickly.

That's the goal, indeed. The quicker you can test, the quicker you can fix
and/or answer. So, it's a win-win. And it allows me to test any fix quickly as
well, and let you know. So, second win-win.

To be honest, I would even wanna go one (huge -- for me, at the moment) step
further (= bridge), and have made up some real test case in this document,
using ERT... and have a pass/fail table... But not able yet to do so...

> Could I ask you to make the source blocks reproducible in the future, so
> that we can execute them without having to alter file paths etc?)

Sure. I'll do.

Here, I could have used another file that I can expect to be always at a fixed
place (like grepping in ~/.emacs or some such).

Generally speaking, you'd want me to pass the path as an Org :var parameter?
Or using default environment vars from the system?

>> #+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).
>>
>> The only difference is the shell command is adding =head -n 3=.
>>
>> * Questions
>>
>> 1. Why that difference of behavior?
>
> I suspect this is due to 
>
> org-babel-min-lines-for-block-output is a variable defined in `ob.el'.
> Its value is 10
>
> Documentation:
> The minimum number of lines for block output.
> If number of lines of output is equal to or exceeds this
> value, the output is placed in a #+begin_example...#+end_example
> block. Otherwise the output is marked as literal by inserting
> colons at the starts of the lines. This variable only takes
> effect if the :results output option is in effect.

OK. Did not know about that.

Not sure, though, that I understand the link between a certain number of
lines, and the type of block the result is wrapped in. I could easily imagine
that every such result would be wrapped in an example block, or -- the
opposite -- that it always is presented with a colon in front of every line.

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

--8<---------------cut here---------------start------------->8---
;; 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)
--8<---------------cut here---------------end--------------->8---

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

Thanks for your answer.

Best regards,
  Seb

-- 
Sébastien Vauban

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode