emacs-orgmode
[Top][All Lists]
Advanced

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

[Orgmode] [Babel] Need for an extra literal block construct


From: Sébastien Vauban
Subject: [Orgmode] [Babel] Need for an extra literal block construct
Date: Fri, 19 Nov 2010 14:27:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (windows-nt)

Hi all,

Sébastien Vauban wrote:
> Rainer M Krug wrote:
>> On 24/09/10 11:28, Sébastien Vauban wrote:
>>> "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.
>>>>>
>>>>>> 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?
>>
>> Probably even one step further: being able to specify the environment to be
>> used in a header argument, so we would have three possible scenarios:
>>
>> 1) default (equals to :wrapper orgresults)   : using \begin{orgresults}
>>    ... \end{orgresult}
>> 2) :nowrapper  : using no wrapper around the results block
>> 3) :wrapper myEnvironment : using \begin{myEnvironment} ...
>>    \end{myEnvironment}
>
> Sure!  This would make *a lot of sense*, IMHO.

Along this (still open -- at least, I hope so) discussion, I have a request
for a new literal block.

Currently, when looking at http://orgmode.org/manual/Literal-examples.html, we
see we only have two "environments" that keep line breaks as they are in the
Org buffer, that is SRC and EXAMPLE, both mapped in HTML to PRE.

- SRC is used for source code blocks
- EXAMPLE, with a too general name (IMO), is used for results of the block
  code execution

But we have nothing else for blocks we would want to present differently.

Since a couple of months, I'm beginning to capture tasks received by emails,
or replies from this list, but they often contain structured replies (lines
prefixed by >) that are unreadable if not presented like they are in Gnus.

Therefore, could we imagine introducting a new block type for emails (for
example)?

Or, if the above gets done, we could have orgresults (for example) used for
the results of SRC blocks, and then keep EXAMPLE for the mails?

What do you think?

Best regards,
  Seb

-- 
Sébastien Vauban




reply via email to

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