emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: [babel] Environment around exported results


From: Sébastien Vauban
Subject: [Orgmode] Re: [babel] Environment around exported results
Date: Fri, 24 Sep 2010 11:28:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <address@hidden> writes:
>> "Eric Schulte" wrote:
>>>> Would you mind creating an LaTeX environment around the =results= block,
>>>> so that we could have the code colorized (via listings or Minted), and
>>>> clearly distinguish the results, if we want so.
>>>>
>>>> Having an environment would allow one to use non-proportional font for
>>>> the results, or a shadowed background, or...
>>>
>>> Would such an environment be in addition too or in place of wrapping
>>> results in the example environment?
>>
>> I would think of something like this:
>>
>> \begin{orgresults}
>> <... results block ...>
>> \end{orgresults}
>>
>> so that one can customize the =orgresults= environment in LaTeX to get a
>> colored background, another font, etc.
>>
>>> What would you suggest for tabular results?
>>
>> Nothing different for tables: just the same plain default environment
>> around the results part.
>>
>>> One very nice property of the current setup is that it relies solely on
>>> vanilla Org-mode for export features. If the example export of Org-mode
>>> allowed some form of customization through a customizable div class or
>>> latex environment would that be sufficient?
>>
>> The name of the environment could be in a variable, yes.
>>
>> But please note the above request can come out of a misunderstanding or
>> poor knowledge of already existing parametrization of Org-Babel. Put me
>> back on tracks if needed...
>
> I think you've made a good point for adding this functionality.

Thanks ;-)

> I'll put this on the Babel TODO stack, and reply to this email when we get
> something implemented.

FYI, I think it such a thing should be on by default, but with a possibility
to disable it, block per block (or subtree, or file, ...).

Something like a =:nowrapper= header argument?

Many thanks in advance...

Best regards,
  Seb

-- 
Sébastien Vauban




reply via email to

[Prev in Thread] Current Thread [Next in Thread]