[babel] Environment around exported results

[babel] Environment around exported results

[Sébastien Vauban]

Hi Dan and Eric,

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

What do you think of this?

Best regards,
  Seb

PS- Maybe the same applies for HTML, with DIV blocks...

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

Re: [babel] Environment around exported results

[Eric Schulte]

Hi Seb,

Would such an environment be in addition too or in place of wrapping
results in the example environment?  What would you suggest for tabular
results?

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?

Best -- Eric

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Dan and Eric,
>
> 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...
>
> What do you think of this?
>
> Best regards,
>   Seb
>
> PS- Maybe the same applies for HTML, with DIV blocks...

Re: [babel] Environment around exported results

[Sébastien Vauban]

Hi Eric,

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

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

Re: [babel] Environment around exported results

[Sébastien Vauban]

Hi Eric,

Sébastien Vauban wrote:
> "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...

To illustrate the output I can currently get (and its corresponding source, in
"vis-à-vis"), go and see http://www.mygooglest.com/sva/ob-exported-results.png.

What I would like, to improve readability, is to be able to put a light green
background for all the generated results, by customizing an added environment
that has been put around the results block.

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

Re: Re: [babel] Environment around exported results

[Eric Schulte]

Hi Seb,

I think you've made a good point for adding this functionality.  I'll
put this on the Babel TODO stack, and reply to this email when we get
something implemented.

Best -- Eric

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> "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...
>
> Best regards,
>   Seb

Re: [babel] Environment around exported results

[Sébastien Vauban]

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> 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


_______________________________________________
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

Re: Re: [babel] Environment around exported results

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/09/10 11:28, Sébastien Vauban wrote:
> Hi Eric,
> 
> "Eric Schulte" wrote:
>> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> 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?

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}

This could possibly even extended to source blocks as well, enabling the
use of different formating for different source blocks?

Cheers,

Rainer

> 
> Many thanks in advance...
> 
> Best regards,
>   Seb
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Tel:        +33 - (0)9 53 10 27 44
Cell:       +27 - (0)8 39 47 90 42
Fax (SA):   +27 - (0)8 65 16 27 82
Fax (D) :   +49 - (0)3 21 21 25 22 44
Fax (FR):   +33 - (0)9 58 10 27 44
email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkydEZYACgkQoYgNqgF2egrXKgCfUK66v+huGysHoau6GRWy0wJr
UOAAmQGHseEUyUzI7pap5nB31SAnIN1T
=tkMG
-----END PGP SIGNATURE-----

Re: [babel] Environment around exported results

[Sébastien Vauban]

Hi Rainer,

Rainer M Krug wrote:
> On 24/09/10 11:28, Sébastien Vauban wrote:
>> "Eric Schulte" wrote:
>>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> 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.


> This could possibly even extended to source blocks as well, enabling the use
> of different formating for different source blocks?

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

[Babel] Need for an extra literal block construct

[Sébastien Vauban]

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 <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMStu3cLTcvVIw@public.gmane.orge.org> 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


_______________________________________________
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

Re: [Babel] Need for an extra literal block construct

[Christian Moe]

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

There's VERSE, too.

Yours,
Christian

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Christian,

Christian Moe wrote:
>> 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.
>
> There's VERSE, too.

#+TITLE:     Is VERSE a real PRE environment?
#+DATE:      2010-11-19
#+LANGUAGE:  en_US

If VERSE was really handled "verbatim" (for lists, etc.), then, yes,
definitively, I don't need a new "environment" for emails. Was forgetting
about that one, thanks for the reminder!

Though, if the following is not a bug, but a deliberative choice, then no,
it's not what I'm looking for...

* Source block

** Source

#+begin_src emacs-lisp
(update this-var)
(echo "OK")
#+end_src

** Results

#+begin_example
<pre class="src src-emacs-lisp">(update this-var)
(echo <span class="org-string">"OK"</span>)
</pre>
#+end_example

* Example

** Source

#+begin_example
>> Does it work?
>
> Yes, if you:
> - update =this-var=
> - restart

OK. Confirmed, but you need to:
1. delete the =cache=.
2. redo it.

Thanks to:
- you
- me
#+end_example

** Results

#+begin_example
<pre class="example">&gt;&gt; Does it work?
&gt;
&gt; Yes, if you:
&gt; - update =this-var=
&gt; - restart

OK. Confirmed, but you need to:
1. delete the =cache=.
2. redo it.

Thanks to:
- you
- me
</pre>
#+end_example

* Verse

** Source

#+begin_verse
>> Does it work?
>
> Yes, if you:
> - update =this-var=
> - restart

OK. Confirmed, but you need to:
1. delete the =cache=.
2. redo it.

Thanks to:
- you
- me
#+end_verse

** Results

#+begin_example
<p class="verse">
&gt;&gt; Does it work?<br/>
&gt;<br/>
&gt; Yes, if you:<br/>

&gt; - update <code>this-var</code><br/>
&gt; - restart<br/>
<br/>
OK. Confirmed, but you need to:<br/>
</p><ol>
<li>
delete the <code>cache</code>.<br/>
</li>

<li>
redo it.<br/>
<br/>
Thanks to:<br/>
</li>
<li>
you<br/>
</li>
<li>
me<br/>
</p>
#+end_example

** Right thing or wrong thing?

The verse "mail" is badly translated into HTML:

1. lists are not copied "verbatim" in the PRE
2. they're even wrong: mix of OL and UL, because there is no ending /OL...

While the second is clearly a bug, what about the first point?

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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi all,

Sébastien Vauban wrote:
> Christian Moe wrote:
>>> 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.
>>
>> There's VERSE, too.
>
> #+TITLE:     Is VERSE a real PRE environment?
>
> #+begin_verse
>>> Does it work?
>>
>> Yes, if you:
>> - update =this-var=
>> - restart
>
> OK. Confirmed, but you need to:
> 1. delete the =cache=.
> 2. redo it.
>
> Thanks to:
> - you
> - me
> #+end_verse
>
> is translated into
>
> #+begin_example
> <p class="verse">
> &gt;&gt; Does it work?<br/>
> &gt;<br/>
> &gt; Yes, if you:<br/>
>
> &gt; - update <code>this-var</code><br/>
> &gt; - restart<br/>
> <br/>
> OK. Confirmed, but you need to:<br/>
> </p><ol>
> <li>
> delete the <code>cache</code>.<br/>
> </li>
>
> <li>
> redo it.<br/>
> <br/>
> Thanks to:<br/>
> </li>
> <li>
> you<br/>
> </li>
> <li>
> me<br/>
> </p>
> #+end_example
>
> ** Right thing or wrong thing?
>
> The verse "mail" is badly translated into HTML: lists are not copied
> "verbatim" in the PRE

*Same for PDF*: the lists in the VERSE environment are interpreted:

--8<---------------cut here---------------start------------->8---
\begin{verse}
>> Does it work?\\
>\\
> Yes, if you:\\
> - update \url{this-var}\\
> - restart\\
\vspace*{1em}
OK. Confirmed, but you need to:\\
\begin{enumerate}
\item delete the \url{cache}.\\
\item redo it.\\
\end{enumerate}

\vspace*{1em}
Thanks to:\\
\begin{itemize}
\item you\\
\item me\\
\end{itemize}

\end{verse}
--8<---------------cut here---------------end--------------->8---

So are the CODE inlined words (delimited by =equal= signs).

- Bug, or
- on purpose?

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

Re: Re: [Babel] Need for an extra literal block construct

[Thomas S. Dye]

Aloha Sébastien,

Just a side comment on the LaTeX output of your example: it is usually  
not a good idea to put markup like \vspace in the .tex file.  Commands  
like \vspace work there, but they defeat the document design of the  
style or class file.  In the ideal case, commands like \vspace are  
confined to style and class files and do not appear in tex files.

Perhaps the \vspace could be eliminated on the way to squashing your  
bug?

All the best,
Tom

On Nov 19, 2010, at 10:26 AM, Sébastien Vauban wrote:

> Hi all,
>
> Sébastien Vauban wrote:
>> Christian Moe wrote:
>>>> 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.
>>>
>>> There's VERSE, too.
>>
>> #+TITLE:     Is VERSE a real PRE environment?
>>
>> #+begin_verse
>>>> Does it work?
>>>
>>> Yes, if you:
>>> - update =this-var=
>>> - restart
>>
>> OK. Confirmed, but you need to:
>> 1. delete the =cache=.
>> 2. redo it.
>>
>> Thanks to:
>> - you
>> - me
>> #+end_verse
>>
>> is translated into
>>
>> #+begin_example
>> <p class="verse">
>> &gt;&gt; Does it work?<br/>
>> &gt;<br/>
>> &gt; Yes, if you:<br/>
>>
>> &gt; - update <code>this-var</code><br/>
>> &gt; - restart<br/>
>> <br/>
>> OK. Confirmed, but you need to:<br/>
>> </p><ol>
>> <li>
>> delete the <code>cache</code>.<br/>
>> </li>
>>
>> <li>
>> redo it.<br/>
>> <br/>
>> Thanks to:<br/>
>> </li>
>> <li>
>> you<br/>
>> </li>
>> <li>
>> me<br/>
>> </p>
>> #+end_example
>>
>> ** Right thing or wrong thing?
>>
>> The verse "mail" is badly translated into HTML: lists are not copied
>> "verbatim" in the PRE
>
> *Same for PDF*: the lists in the VERSE environment are interpreted:
>
> --8<---------------cut here---------------start------------->8---
> \begin{verse}
>>> Does it work?\\
>> \\
>> Yes, if you:\\
>> - update \url{this-var}\\
>> - restart\\
> \vspace*{1em}
> OK. Confirmed, but you need to:\\
> \begin{enumerate}
> \item delete the \url{cache}.\\
> \item redo it.\\
> \end{enumerate}
>
> \vspace*{1em}
> Thanks to:\\
> \begin{itemize}
> \item you\\
> \item me\\
> \end{itemize}
>
> \end{verse}
> --8<---------------cut here---------------end--------------->8---
>
> So are the CODE inlined words (delimited by =equal= signs).
>
> - Bug, or
> - on purpose?
>
> Best regards,
>  Seb
>
> -- 
> Sébastien Vauban
>
>
> _______________________________________________
> 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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Thomas,

"Thomas S. Dye" wrote:
> On Nov 19, 2010, at 10:26 AM, Sébastien Vauban wrote:
>> *Same for PDF*: the lists in the VERSE environment are interpreted:
>>
>> --8<---------------cut here---------------start------------->8---
>> \begin{verse}
>>>> Does it work?\\
>>> \\
>>> Yes, if you:\\
>>> - update \url{this-var}\\
>>> - restart\\
>> \vspace*{1em}
>> OK. Confirmed, but you need to:\\
>> \begin{enumerate}
>> \item delete the \url{cache}.\\
>> \item redo it.\\
>> \end{enumerate}
>>
>> \vspace*{1em}
>> Thanks to:\\
>> \begin{itemize}
>> \item you\\
>> \item me\\
>> \end{itemize}
>>
>> \end{verse}
>> --8<---------------cut here---------------end--------------->8---
>
> Just a side comment on the LaTeX output of your example: it is usually not a
> good idea to put markup like \vspace in the .tex file. Commands like \vspace
> work there, but they defeat the document design of the style or class file.
> In the ideal case, commands like \vspace are confined to style and class
> files and do not appear in tex files.
>
> Perhaps the \vspace could be eliminated on the way to squashing your bug?

Just to be sure we talk of the same thing, the \vspace is not introduced by
me. It's something automatically inserted in the TeX during the VERSE
conversion.

I think it's clear to you, but let's state it clearly...

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

Re: Re: [Babel] Need for an extra literal block construct

[Thomas S. Dye]

[-- Attachment #1.1: Type: text/plain, Size: 1653 bytes --]

Aloha Séb,

On Nov 19, 2010, at 12:02 PM, Sébastien Vauban wrote:

> Hi Thomas,
>
> "Thomas S. Dye" wrote:
>> On Nov 19, 2010, at 10:26 AM, Sébastien Vauban wrote:
>>> *Same for PDF*: the lists in the VERSE environment are interpreted:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> \begin{verse}
>>>>> Does it work?\\
>>>> \\
>>>> Yes, if you:\\
>>>> - update \url{this-var}\\
>>>> - restart\\
>>> \vspace*{1em}
>>> OK. Confirmed, but you need to:\\
>>> \begin{enumerate}
>>> \item delete the \url{cache}.\\
>>> \item redo it.\\
>>> \end{enumerate}
>>>
>>> \vspace*{1em}
>>> Thanks to:\\
>>> \begin{itemize}
>>> \item you\\
>>> \item me\\
>>> \end{itemize}
>>>
>>> \end{verse}
>>> --8<---------------cut here---------------end--------------->8---
>>
>> Just a side comment on the LaTeX output of your example: it is  
>> usually not a
>> good idea to put markup like \vspace in the .tex file. Commands  
>> like \vspace
>> work there, but they defeat the document design of the style or  
>> class file.
>> In the ideal case, commands like \vspace are confined to style and  
>> class
>> files and do not appear in tex files.
>>
>> Perhaps the \vspace could be eliminated on the way to squashing  
>> your bug?
>
> Just to be sure we talk of the same thing, the \vspace is not  
> introduced by
> me. It's something automatically inserted in the TeX during the VERSE
> conversion.
>
> I think it's clear to you, but let's state it clearly...
>
> Best regards,
>  Seb
>
> -- 
> Sébastien Vauban

Yes, that's what I meant.  Apologies for any ambiguity.

Tom


[-- Attachment #1.2: Type: text/html, Size: 4423 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: Re: [Babel] Need for an extra literal block construct

[Eric Schulte]

Hi Seb,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

>
> *Same for PDF*: the lists in the VERSE environment are interpreted:
>
...
>
> So are the CODE inlined words (delimited by =equal= signs).
>
> - Bug, or
> - on purpose?
>

I believe that this is on purpose, otherwise I don't see why verse would
be any different from example.  I think of verse as a quote where
newlines are enforced (making it good for mail because you don't end up
with ">"s stacked in the middle of your paragraphs)

I think you may want to look at org-exp-blocks.el, it allows extensible
block syntax so that a user can define his/her own types and how they
will be exported.  This would be useful for custom export of the
proposed future babel results block (which I promise I'll implement
soon).

Best -- Eric

>
> Best regards,
>   Seb

Re: [Babel] Need for an extra literal block construct

[Dan Davison]

Hi Seb,

In addition to the Org example, would you mind supplying a concise,
explicit statement of what the putative bug is? With just the Org
example on its own, the bug is implicit and I at least feel that I'm
having to work hard to get there!

Dan

p.s. However, your emails did motivate the following trivial function a
few months ago which I now use every day for various purposes.

(defun dan/switch-to-org-scratch ()
  "Switch to a temp Org buffer.
If the region is active, insert it."
  (interactive)
  (let ((contents
         (and (region-active-p)
              (buffer-substring (region-beginning)
                                (region-end)))))
    (find-file "/tmp/org-scratch.org")
    (if contents (insert contents))))

Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:

> Hi Christian,
>
> Christian Moe wrote:
>>> 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.
>>
>> There's VERSE, too.
>
> #+TITLE:     Is VERSE a real PRE environment?
> #+DATE:      2010-11-19
> #+LANGUAGE:  en_US
>
> If VERSE was really handled "verbatim" (for lists, etc.), then, yes,
> definitively, I don't need a new "environment" for emails. Was forgetting
> about that one, thanks for the reminder!
>
> Though, if the following is not a bug, but a deliberative choice, then no,
> it's not what I'm looking for...
>
> * Source block
>
> ** Source
>
> #+begin_src emacs-lisp
> (update this-var)
> (echo "OK")
> #+end_src
>
> ** Results
>
> #+begin_example
> <pre class="src src-emacs-lisp">(update this-var)
> (echo <span class="org-string">"OK"</span>)
> </pre>
> #+end_example
>
>
> * Example
>
> ** Source
>
> #+begin_example
>>> Does it work?
>>
>> Yes, if you:
>> - update =this-var=
>> - restart
>
> OK. Confirmed, but you need to:
> 1. delete the =cache=.
> 2. redo it.
>
> Thanks to:
> - you
> - me
> #+end_example
>
>
> ** Results
>
> #+begin_example
> <pre class="example">&gt;&gt; Does it work?
> &gt;
> &gt; Yes, if you:
> &gt; - update =this-var=
> &gt; - restart
>
> OK. Confirmed, but you need to:
> 1. delete the =cache=.
> 2. redo it.
>
> Thanks to:
> - you
> - me
> </pre>
> #+end_example
>
>
> * Verse
>
> ** Source
>
> #+begin_verse
>>> Does it work?
>>
>> Yes, if you:
>> - update =this-var=
>> - restart
>
> OK. Confirmed, but you need to:
> 1. delete the =cache=.
> 2. redo it.
>
> Thanks to:
> - you
> - me
> #+end_verse
>
>
> ** Results
>
> #+begin_example
> <p class="verse">
> &gt;&gt; Does it work?<br/>
> &gt;<br/>
> &gt; Yes, if you:<br/>
>
> &gt; - update <code>this-var</code><br/>
> &gt; - restart<br/>
> <br/>
> OK. Confirmed, but you need to:<br/>
> </p><ol>
> <li>
> delete the <code>cache</code>.<br/>
> </li>
>
> <li>
> redo it.<br/>
> <br/>
> Thanks to:<br/>
> </li>
> <li>
> you<br/>
> </li>
> <li>
> me<br/>
> </p>
> #+end_example
>
>
> ** Right thing or wrong thing?
>
> The verse "mail" is badly translated into HTML:
>
> 1. lists are not copied "verbatim" in the PRE
> 2. they're even wrong: mix of OL and UL, because there is no ending /OL...
>
> While the second is clearly a bug, what about the first point?
>
> Best regards,
>   Seb

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Thomas,

"Thomas S. Dye" wrote:
> On Nov 19, 2010, at 12:02 PM, Sébastien Vauban wrote:
>> "Thomas S. Dye" wrote:
>>> On Nov 19, 2010, at 10:26 AM, Sébastien Vauban wrote:
>>>> *Same for PDF*: the lists in the VERSE environment are interpreted:
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> \begin{verse}
>>>>>> Does it work?\\
>>>>> \\
>>>>> Yes, if you:\\
>>>>> - update \url{this-var}\\
>>>>> - restart\\
>>>> \vspace*{1em}
>>>> OK. Confirmed, but you need to:\\
>>>> \begin{enumerate}
>>>> \item delete the \url{cache}.\\
>>>> \item redo it.\\
>>>> \end{enumerate}
>>>>
>>>> \vspace*{1em}
>>>> Thanks to:\\
>>>> \begin{itemize}
>>>> \item you\\
>>>> \item me\\
>>>> \end{itemize}
>>>>
>>>> \end{verse}
>>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Just a side comment on the LaTeX output of your example: it is usually not
>>> a good idea to put markup like \vspace in the .tex file. Commands like
>>> \vspace work there, but they defeat the document design of the style or
>>> class file. In the ideal case, commands like \vspace are confined to style
>>> and class files and do not appear in tex files.
>>>
>>> Perhaps the \vspace could be eliminated on the way to squashing your bug?
>>
>> Just to be sure we talk of the same thing, the \vspace is not introduced by
>> me. It's something automatically inserted in the TeX during the VERSE
>> conversion.
>>
>> I think it's clear to you, but let's state it clearly...
>
> Yes, that's what I meant.  Apologies for any ambiguity.

No worry!  It's simply because I misunderstood it when reading it the first
time. Maybe because I read too quickly, because English is not my mother
tongue, or because it's already late for me. Or a bit of all 3 reasons...

Thanks, clearly, for attaching importance to this post!... and for passing
extra information...

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

Re: Re: [Babel] Need for an extra literal block construct

[Eric Schulte]

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

"Eric Schulte" <schulte.eric@gmail.com> writes:

> This would be useful for custom export of the proposed future babel
> results block (which I promise I'll implement soon).

An experimental patch implementing wrapping of results using a new
"wrap" :results header argument is attached.  Here is an example of its
usage.

** introducing =wrap= header argument
#+begin_src emacs-lisp :results wrap
  (mapcar (lambda (el) (list el (+ 1 (* el el)))) (number-sequence 0 10))
#+end_src

#+results:
#+BEGIN_RESULT
|  0 |   1 |
|  1 |   2 |
|  2 |   5 |
|  3 |  10 |
|  4 |  17 |
|  5 |  26 |
|  6 |  37 |
|  7 |  50 |
|  8 |  65 |
|  9 |  82 |
| 10 | 101 |
#+END_RESULT

now indented
- first
- second
  #+begin_src emacs-lisp :results wrap
    "something else"
  #+end_src

  #+results:
  #+BEGIN_RESULT
  : something else
  #+END_RESULT


I haven't applied it directly to the repository because I fear it could
have negative effects on the wrapping of results in HTML and LaTeX
blocks, so if any brave souls could try this out over the next day or
two and let me know how it works I'd then feel much more comfortable
about dropping it into the core.

Best -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-wrap-results-header-argument-wraps-code-block-result.patch --]
[-- Type: text/x-diff, Size: 5422 bytes --]

From e2589d43280164dbcb2e1d3b18ef6bf23ac99b6b Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 19 Nov 2010 16:04:59 -0700
Subject: [PATCH] "wrap" :results header argument wraps code block results

* lisp/ob.el (org-babel-insert-result): Responds to new "wrap" header
  argument.
  (org-babel-merge-params): Includes new "wrap" header argument in
  one of the results header argument exclusive groups.
---
 lisp/ob.el |   72 +++++++++++++++++++++++++++++------------------------------
 1 files changed, 35 insertions(+), 37 deletions(-)

diff --git a/lisp/ob.el b/lisp/ob.el
index 3689619..9feb0a6 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -1433,11 +1433,11 @@ code ---- the results are extracted in the syntax of the source
 	    (delete-region (point) (org-babel-result-end)))
 	   ((member "append" result-params)
 	    (goto-char (org-babel-result-end)) (setq beg (point)))
-	   ((member "prepend" result-params) ;; already there
-	    )))
+	   ((member "prepend" result-params)))) ; already there
 	(setq results-switches
 	      (if results-switches (concat " " results-switches) ""))
-	(cond
+	;; insert results based on type
+	(cond			     
 	 ;; do nothing for an empty result
 	 ((= (length result) 0))
 	 ;; insert a list if preferred
@@ -1449,6 +1449,7 @@ code ---- the results are extracted in the syntax of the source
 				 '(:splicep nil :istart "- " :iend "\n")))))
 	 ;; assume the result is a table if it's not a string
 	 ((not (stringp result))
+	  (goto-char beg)
 	  (insert (concat (orgtbl-to-orgtbl
 			   (if (or (eq 'hline (car result))
 				   (and (listp (car result))
@@ -1458,24 +1459,30 @@ code ---- the results are extracted in the syntax of the source
 	  (goto-char beg) (when (org-at-table-p) (org-table-align)))
 	 ((member "file" result-params)
 	  (insert result))
-	 ((member "html" result-params)
-	  (insert (format "#+BEGIN_HTML%s\n%s#+END_HTML\n"
-			  results-switches result)))
-	 ((member "latex" result-params)
-	  (insert (format "#+BEGIN_LaTeX%s\n%s#+END_LaTeX\n"
-			  results-switches result)))
-	 ((member "code" result-params)
-	  (insert (format "#+BEGIN_SRC %s%s\n%s#+END_SRC\n"
-			  (or lang "none") results-switches result)))
-	 ((member "org" result-params)
-	  (insert (format "#+BEGIN_SRC org\n%s#+END_SRC\n" result)))
-	 ((member "raw" result-params)
-	  (save-excursion (insert result)) (if (org-at-table-p) (org-cycle)))
-	 (t
-	  (org-babel-examplize-region
-	   (point) (progn (insert result) (point)) results-switches)))
-	;; possibly indent the results to match the #+results line
+	 (t (goto-char beg)
+	    (org-babel-examplize-region
+	     (point) (progn (insert result) (point)) results-switches)))
 	(setq end (if (listp result) (org-table-end) (point)))
+	;; possibly wrap result
+	(flet ((wrap (start finish)
+		     (goto-char beg) (insert start)
+		     (goto-char (+ (if (listp result) 0 (length start)) end))
+		     (insert finish) (setq end (point))))
+	  (cond
+	   ((member "html" result-params)
+	    (wrap "#+BEGIN_HTML\n" "#+END_HTML"))
+	   ((member "latex" result-params)
+	    (wrap "#+BEGIN_LaTe\n" "#+END_LaTeX"))
+	   ((member "code" result-params)
+	    (wrap (format "#+BEGIN_SRC %s%s\n" (or lang "none") results-switches)
+		  "#+END_SRC"))
+	   ((member "org" result-params)
+	    (wrap "#+BEGIN_ORG\n" "#+END_ORG"))
+	   ((member "raw" result-params)
+	    (goto-char beg) (if (org-at-table-p) (org-cycle)))
+	   ((member "wrap" result-params)
+	    (wrap "#+BEGIN_RESULT\n" "#+END_RESULT"))))
+	;; possibly indent the results to match the #+results line
 	(when (and indent (> indent 0)
 		   ;; in this case `table-align' does the work for us
 		   (not (and (listp result)
@@ -1503,22 +1510,13 @@ code ---- the results are extracted in the syntax of the source
      ((org-at-table-p) (progn (goto-char (org-table-end)) (point)))
      ((org-in-item-p) (- (org-list-bottom-point) 1))
      (t
-      (let ((case-fold-search t))
-        (cond
-         ((looking-at "[ \t]*#\\+begin_latex")
-          (re-search-forward "[ \t]*#\\+end_latex" nil t)
-          (forward-line 1))
-         ((looking-at "[ \t]*#\\+begin_html")
-          (re-search-forward "[ \t]*#\\+end_html" nil t)
-          (forward-line 1))
-         ((looking-at "[ \t]*#\\+begin_example")
-          (re-search-forward "[ \t]*#\\+end_example" nil t)
-          (forward-line 1))
-         ((looking-at "[ \t]*#\\+begin_src")
-          (re-search-forward "[ \t]*#\\+end_src" nil t)
-          (forward-line 1))
-         (t (progn (while (looking-at "[ \t]*\\(: \\|\\[\\[\\)")
-                     (forward-line 1))))))
+      (let ((case-fold-search t)
+	    (blocks-re (regexp-opt
+			(list "latex" "html" "example" "src" "result"))))
+	(if (looking-at (concat "[ \t]*#\\+begin_" blocks-re))
+	    (re-search-forward (concat "[ \t]*#\\+end_" blocks-re) nil t)
+	  (while (looking-at "[ \t]*\\(: \\|\\[\\[\\)")
+	    (forward-line 1))))
       (point)))))
 
 (defun org-babel-result-to-file (result)
@@ -1570,7 +1568,7 @@ This takes into account some special considerations for certain
 parameters when merging lists."
   (let ((results-exclusive-groups
 	 '(("file" "list" "vector" "table" "scalar" "raw" "org"
-            "html" "latex" "code" "pp")
+            "html" "latex" "code" "pp" "wrap")
 	   ("replace" "silent" "append" "prepend")
 	   ("output" "value")))
 	(exports-exclusive-groups
-- 
1.7.0.4


[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: Re: [Babel] Need for an extra literal block construct

[Christian Moe]

Hi,

Perhaps I misunderstood what you're after. As I now understand it, you 
want line breaks preserved and you don't want anything interpreted, 
you want verbatim text. Why doesn't EXAMPLE meet your needs?

Yours,
Christian

On 11/19/10 9:12 PM, Sébastien Vauban wrote:
> Hi Christian,
>
> Christian Moe wrote:
>>> 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.
>>
>> There's VERSE, too.
>
> #+TITLE:     Is VERSE a real PRE environment?
> #+DATE:      2010-11-19
> #+LANGUAGE:  en_US
>
> If VERSE was really handled "verbatim" (for lists, etc.), then, yes,
> definitively, I don't need a new "environment" for emails. Was forgetting
> about that one, thanks for the reminder!
>
> Though, if the following is not a bug, but a deliberative choice, then no,
> it's not what I'm looking for...
>
> * Source block
>
> ** Source
>
> #+begin_src emacs-lisp
> (update this-var)
> (echo "OK")
> #+end_src
>
> ** Results
>
> #+begin_example
> <pre class="src src-emacs-lisp">(update this-var)
> (echo<span class="org-string">"OK"</span>)
> </pre>
> #+end_example
>
> * Example
>
> ** Source
>
> #+begin_example
>>> Does it work?
>>
>> Yes, if you:
>> - update =this-var=
>> - restart
>
> OK. Confirmed, but you need to:
> 1. delete the =cache=.
> 2. redo it.
>
> Thanks to:
> - you
> - me
> #+end_example
>
> ** Results
>
> #+begin_example
> <pre class="example">&gt;&gt; Does it work?
> &gt;
> &gt; Yes, if you:
> &gt; - update =this-var=
> &gt; - restart
>
> OK. Confirmed, but you need to:
> 1. delete the =cache=.
> 2. redo it.
>
> Thanks to:
> - you
> - me
> </pre>
> #+end_example
>
> * Verse
>
> ** Source
>
> #+begin_verse
>>> Does it work?
>>
>> Yes, if you:
>> - update =this-var=
>> - restart
>
> OK. Confirmed, but you need to:
> 1. delete the =cache=.
> 2. redo it.
>
> Thanks to:
> - you
> - me
> #+end_verse
>
> ** Results
>
> #+begin_example
> <p class="verse">
> &gt;&gt; Does it work?<br/>
> &gt;<br/>
> &gt; Yes, if you:<br/>
>
> &gt; - update<code>this-var</code><br/>
> &gt; - restart<br/>
> <br/>
> OK. Confirmed, but you need to:<br/>
> </p><ol>
> <li>
> delete the<code>cache</code>.<br/>
> </li>
>
> <li>
> redo it.<br/>
> <br/>
> Thanks to:<br/>
> </li>
> <li>
> you<br/>
> </li>
> <li>
> me<br/>
> </p>
> #+end_example
>
> ** Right thing or wrong thing?
>
> The verse "mail" is badly translated into HTML:
>
> 1. lists are not copied "verbatim" in the PRE
> 2. they're even wrong: mix of OL and UL, because there is no ending /OL...
>
> While the second is clearly a bug, what about the first point?
>
> Best regards,
>    Seb
>

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> *Same for PDF*: the lists in the VERSE environment are interpreted.
>> So are the CODE inlined words (delimited by =equal= signs).
>>
>> - Bug, or
>> - on purpose?
>
> I believe that this is on purpose,

I'd like to have an "official" answer on this, because I really would have
thought the contrary.

> otherwise I don't see why verse would be any different from example.

Of course, that's kinda true but...

> I think of verse as a quote where newlines are enforced (making it good for
> mail because you don't end up with ">"s stacked in the middle of your
> paragraphs)

if the above behavior is wanted, then I cannot use VERSE for mails. Because it
will corrupt the email layout in both HTML and PDF (for example, in passages
of the email that would not be prefixed by >).

> I think you may want to look at org-exp-blocks.el, it allows extensible
> block syntax so that a user can define his/her own types and how they will
> be exported.

Rigth point. I did not think anymore of that one. Though, I would like all my
documents (even with cited emails) to be compilable by anybody, in both HTML
and PDF, without requiring a special customization in the .emacs file, in the
CSS or in the LaTeX classes). Hence, I really would like avoiding to introduce
my own "tags".

> This would be useful for custom export of the proposed future babel results
> block (which I promise I'll implement soon).

I don't wanna hurry you on this. If I plugged this post to that old thread,
it's because they really are (more than) related to each other.

Of course, I'll be excited to try and use what you will produce in that
direction, but you can spend time first on more important things (if
any!? ;-)).

BTW, once you will have implemented that, I will be able to use QUOTE for
email passages, and your new environment will be compilable without requiring
any custom add-on. So, that should answer fully this.

Thanks a lot!

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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Christian,

Christian Moe wrote:
> Perhaps I misunderstood what you're after. As I now understand it, you want
> line breaks preserved and you don't want anything interpreted, you want
> verbatim text. Why doesn't EXAMPLE meet your needs?

Because there are clearly 3 key "concepts" to be able to distinguish in nice
HTML/PDF output:

- Code fragments :: text files that use the specific numbers of spaces and
  characters to line things up.

- Sample output :: Output from programs, scripts or commands.

- Text giving instructions :: Typically used for quoting passages of an email
  message.

The first one is covered in HTML by the src class and in PDF by listings.

The last two are currently handled the same way (ie, not distinguishable). In
HTML, both are mapped onto EXAMPLE.

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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Eric,

"Eric Schulte" wrote:
> "Eric Schulte" <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> This would be useful for custom export of the proposed future babel
>> results block (which I promise I'll implement soon).
>
> An experimental patch implementing wrapping of results using a new
> "wrap" :results header argument is attached.  Here is an example of its
> usage.
>
> ** introducing =wrap= header argument
> #+begin_src emacs-lisp :results wrap
>   (mapcar (lambda (el) (list el (+ 1 (* el el)))) (number-sequence 0 10))
> #+end_src
>
> #+results:
> #+BEGIN_RESULT
> |  0 |   1 |
> |  1 |   2 |
> |  2 |   5 |
> |  3 |  10 |
> |  4 |  17 |
> |  5 |  26 |
> |  6 |  37 |
> |  7 |  50 |
> |  8 |  65 |
> |  9 |  82 |
> | 10 | 101 |
> #+END_RESULT
>
>
> now indented
> - first
> - second
>   #+begin_src emacs-lisp :results wrap
>     "something else"
>   #+end_src
>
>
>   #+results:
>   #+BEGIN_RESULT
>   : something else
>   #+END_RESULT
>
>
>
> I haven't applied it directly to the repository because I fear it could
> have negative effects on the wrapping of results in HTML and LaTeX
> blocks, so if any brave souls could try this out over the next day or
> two and let me know how it works I'd then feel much more comfortable
> about dropping it into the core.

Waoouwww, that was quick!

I'll patch my system and test it this evening. Thank you *very much*...

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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

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

Hi Dan,

Dan Davison wrote:
> In addition to the Org example, would you mind supplying a concise, explicit
> statement of what the putative bug is? With just the Org example on its own,
> the bug is implicit and I at least feel that I'm having to work hard to get
> there!

Hope this helps!

#+TITLE:     ecm-verse-2.txt
#+DATE:      2010-11-20
#+LANGUAGE:  en_US

#+LaTeX_CLASS: mcarticle
#+LaTeX_CLASS_OPTIONS: [final]

* Context

There are clearly 3 key "concepts" to be able to distinguish in nice HTML
output:

- Code fragments :: text files that use the specific numbers of spaces and
  characters to line things up.

- Sample output :: Output from programs, scripts or commands.

- Text giving instructions :: Typically used for quoting passages of an email
  message.

* Examples

** Code fragment

#+begin_src emacs-lisp
(update this-var)
(echo "OK")
#+end_src

** Sample output

The results of code execution is currently (or /was/ -- I need to test the
patch of Eric) translated into HTML as EXAMPLE.

#+begin_src sh :results output :exports both
ls *.org
#+end_src

#+results:
| Agenda-Sorting-Strategy.org |
| Clock-Report.org            |
| org-beamer-fpu-rules.org    |
| org-hist.org                |

** Text giving instructions

EXAMPLE begin taken, if I want another "verbatim" environment, the only left
to me, in HTML, is VERSE.

#+begin_verse
Hi Seb,

In addition to the Org example, would you mind supplying a concise,
explicit statement of what the putative bug is?  With just the Org
example on its own:

- the bug is implicit and
- I at least feel that I'm having to work hard to get there!

Dan
#+end_verse

From [[http://mid.gmane.org/87mxp5q6uf.fsf%40gmail.com][Email from Dan Davison: Re: {Babel} Need for an extra ]]

*I'd expect to see all the above passage from the email to be uninterpreted*. It
is not acting that way.

See attachment for what I'm heading to.


> p.s. However, your emails did motivate the following trivial function a
> few months ago which I now use every day for various purposes.
>
> (defun dan/switch-to-org-scratch ()
>   "Switch to a temp Org buffer.
> If the region is active, insert it."
>   (interactive)
>   (let ((contents
>          (and (region-active-p)
>               (buffer-substring (region-beginning)
>                                 (region-end)))))
>     (find-file "/tmp/org-scratch.org")
>     (if contents (insert contents))))

Thanks for sharing this... Always interesting to see what others do, what does
help them in their workflows...

Best regards,
  Seb

-- 
Sébastien Vauban

[-- Attachment #2: ecm-verse-2.png --]
[-- Type: image/png, Size: 175156 bytes --]

[-- Attachment #3: Type: text/plain, Size: 222 bytes --]

_______________________________________________
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

Re: [Babel] Need for an extra literal block construct

[Dan Davison]

Hi Seb,

What I was trying to say is that with bug reports it is helpful if the
first one or two sentences of the email are a precise and brief
statement of what is going wrong. Then the reader can decide if she
wants to continue to the more detailed and discursive material.

Dan

Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:

> Hi Dan,
>
> Dan Davison wrote:
>> In addition to the Org example, would you mind supplying a concise, explicit
>> statement of what the putative bug is? With just the Org example on its own,
>> the bug is implicit and I at least feel that I'm having to work hard to get
>> there!
>
> Hope this helps!
>
> #+TITLE:     ecm-verse-2.txt
> #+DATE:      2010-11-20
> #+LANGUAGE:  en_US
>
> #+LaTeX_CLASS: mcarticle
> #+LaTeX_CLASS_OPTIONS: [final]
>
> * Context
>
> There are clearly 3 key "concepts" to be able to distinguish in nice HTML
> output:
>
> - Code fragments :: text files that use the specific numbers of spaces and
>   characters to line things up.
>
> - Sample output :: Output from programs, scripts or commands.
>
> - Text giving instructions :: Typically used for quoting passages of an email
>   message.
>
> * Examples
>
> ** Code fragment
>
> #+begin_src emacs-lisp
> (update this-var)
> (echo "OK")
> #+end_src
>
> ** Sample output
>
> The results of code execution is currently (or /was/ -- I need to test the
> patch of Eric) translated into HTML as EXAMPLE.
>
> #+begin_src sh :results output :exports both
> ls *.org
> #+end_src
>
> #+results:
> | Agenda-Sorting-Strategy.org |
> | Clock-Report.org            |
> | org-beamer-fpu-rules.org    |
> | org-hist.org                |
>
> ** Text giving instructions
>
> EXAMPLE begin taken, if I want another "verbatim" environment, the only left
> to me, in HTML, is VERSE.
>
> #+begin_verse
> Hi Seb,
>
> In addition to the Org example, would you mind supplying a concise,
> explicit statement of what the putative bug is?  With just the Org
> example on its own:
>
> - the bug is implicit and
> - I at least feel that I'm having to work hard to get there!
>
> Dan
> #+end_verse
>
>
> From [[http://mid.gmane.org/87mxp5q6uf.fsf%40gmail.com][Email from Dan Davison: Re: {Babel} Need for an extra ]]
>
> *I'd expect to see all the above passage from the email to be uninterpreted*. It
> is not acting that way.
>
> See attachment for what I'm heading to.
>
>
>> p.s. However, your emails did motivate the following trivial function a
>> few months ago which I now use every day for various purposes.
>>
>> (defun dan/switch-to-org-scratch ()
>>   "Switch to a temp Org buffer.
>> If the region is active, insert it."
>>   (interactive)
>>   (let ((contents
>>          (and (region-active-p)
>>               (buffer-substring (region-beginning)
>>                                 (region-end)))))
>>     (find-file "/tmp/org-scratch.org")
>>     (if contents (insert contents))))
>
> Thanks for sharing this... Always interesting to see what others do, what does
> help them in their workflows...
>
> Best regards,
>   Seb

Re: Re: [Babel] Need for an extra literal block construct

[Nicolas Goaziou]

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

Hello,

>>>>> Sébastien Vauban writes:

> I'd expect to see all the above passage from the email to be
> uninterpreted. It is not acting that way.

According to the manual, VERSE block only preserves line breaks and
leading white spaces. Otherwise it is _normal_ formatting. Though,
this raises an interesting question about lists.

At the moment, by design, Org doesn't recognize lists inside blocks.
While this is obviously the way to go in SRC EXAMPLE and COMMENT
blocks, it isn't as clear with VERSE, CENTER and QUOTE.

In the case of VERSE, preserving leading white spaces cannot cooperate
with list exporting. So I still think lists shouldn't be interpreted
here and, as such, not recognized there either. On the other side, in
CENTER and QUOTE blocks, Org may be able to understand them (they are
correctly exported in those cases).

I could make this distinction when I'll update list model. For now, I
suggest using the first patch, which simply ignores lists in HTML and
LaTeX when in a VERSE block.

There are some other problems with those blocks. You can, for example,
replacing your bullets with stars, and export again. This will become
headings in a verse environment. I could bet this wasn't intended.
This is because text as the same column as VERSE block header is
pasted in the temporary buffer at column 0. Items thus become
headings. The second patch prevents headlines inside blocks from being
interpreted.

Regards,

-- Nicolas


[-- Attachment #2: 0001-Do-not-interpret-lists-in-verse-environments-upon-ex.patch --]
[-- Type: text/plain, Size: 2733 bytes --]

From c0c3f11916bae6731eec26e4743402bf3aa83d2f Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Sun, 21 Nov 2010 12:01:59 +0100
Subject: [PATCH 1/2] Do not interpret lists in verse environments upon exporting

* lisp/org-html.el (org-export-as-html): skip list interpretation when
  inside a verse block

This change isn't needed in DocBook exporter, which treats VERSE as
QUOTE environment.
---
 lisp/org-html.el  |    6 ++++--
 lisp/org-latex.el |    9 +++++++++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/lisp/org-html.el b/lisp/org-html.el
index d1fe06d..1a3e673 100644
--- a/lisp/org-html.el
+++ b/lisp/org-html.el
@@ -1549,13 +1549,15 @@ lang=\"%s\" xml:lang=\"%s\">
 	      (insert (org-format-table-html table-buffer table-orig-buffer))))
 	   (t
 	    ;; Normal lines
-	    (when (string-match
+	    (when (and
+		   (not inverse)
+		   (string-match
 		   (cond
 		    ((eq llt t) "^\\([ \t]*\\)\\(\\([-+*] \\)\\|\\([0-9]+[.)]\\) \\)?\\( *[^ \t\n\r]\\|[ \t]*$\\)")
 		    ((= llt ?.) "^\\([ \t]*\\)\\(\\([-+*] \\)\\|\\([0-9]+\\.\\) \\)?\\( *[^ \t\n\r]\\|[ \t]*$\\)")
 		    ((= llt ?\)) "^\\([ \t]*\\)\\(\\([-+*] \\)\\|\\([0-9]+)\\) \\)?\\( *[^ \t\n\r]\\|[ \t]*$\\)")
 		    (t (error "Invalid value of `org-plain-list-ordered-item-terminator'")))
-		   line)
+		   line))
 	      (setq ind (or (get-text-property 0 'original-indentation line)
 			    (org-get-string-indentation line))
 		    item-type (if (match-beginning 4) "o" "u")
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 91bf380..75d9ce2 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -2214,14 +2214,23 @@ The conversion is made depending of STRING-BEFORE and STRING-AFTER."
     (org-replace-match-keep-properties "\\begin{verse}" t t)
     (beginning-of-line 2)
     (while (and (not (looking-at "[ \t]*ORG-VERSE-END.*")) (not (eobp)))
+      ;; Replace leading white spaces.
       (when (looking-at "\\([ \t]+\\)\\([^ \t\n]\\)")
 	(goto-char (match-end 1))
 	(org-replace-match-keep-properties
 	 (org-export-latex-protect-string
 	  (concat "\\hspace*{1cm}" (match-string 2))) t t)
 	(beginning-of-line 1))
+      ;; When at a list item, protect its bullet to avoid later
+      ;; interpretation. This is only needed for items at the same
+      ;; column as block header.
+      (when (looking-at org-item-beginning-re)
+	(add-text-properties
+	 (match-beginning 1) (match-end 1) '(org-protected t)))
+      ;; Replace empty lines.
       (if (looking-at "[ \t]*$")
 	  (insert (org-export-latex-protect-string "\\vspace*{1em}"))
+	;; Add \\ to the end of line if necessary.
 	(unless (looking-at ".*?[^ \t\n].*?\\\\\\\\[ \t]*$")
 	  (end-of-line 1)
 	  (insert "\\\\")))
-- 
1.7.3.2


[-- Attachment #3: 0002-Prevent-exporters-to-find-headlines-within-blocks.patch --]
[-- Type: text/plain, Size: 5935 bytes --]

From a26ade00a90afa73fb709080fa17ece2997b3a57 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Sun, 21 Nov 2010 13:42:32 +0100
Subject: [PATCH 2/2] Prevent exporters to find headlines within blocks

* lisp/org-exp.el (org-export-mark-blockquote-verse-center): Protect
  headlines within blocks. As leading white spaces are removed from
  text inside blocks, a line starting with some spaces and some starts
  would be considered as an headline otherwise.
* lisp/org-html.el (org-export-as-html): added some predicates to
  identify what type of block current line is in. Do not recognize
  headlines in such blocks
* lisp/org-docbook.el (org-export-as-docbook): added some predicates
  to identify what type of block current line is in. Do not recognize
  headlines in such blocks
---
 lisp/org-docbook.el |   19 ++++++++++++++-----
 lisp/org-exp.el     |    7 ++++++-
 lisp/org-html.el    |   17 +++++++++++++----
 3 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/lisp/org-docbook.el b/lisp/org-docbook.el
index 7d90ec3..b0ddbce 100644
--- a/lisp/org-docbook.el
+++ b/lisp/org-docbook.el
@@ -496,9 +496,11 @@ publishing directory."
 	 (html-table-tag (plist-get opt-plist :html-table-tag))
 	 (quote-re0   (concat "^[ \t]*" org-quote-string "\\>"))
 	 (quote-re    (concat "^\\(\\*+\\)\\([ \t]+" org-quote-string "\\>\\)"))
-	 (inquote     nil)
-	 (infixed     nil)
-	 (inverse     nil)
+	 (inquote      nil)
+	 (inblockquote nil)
+	 (infixed      nil)
+	 (inverse      nil)
+	 (incenter     nil)
 	 (in-local-list nil)
 	 (local-list-type nil)
 	 (local-list-indent nil)
@@ -706,7 +708,8 @@ publishing directory."
 	    (throw 'nextline nil))
 
 	  ;; Start of block quotes and verses
-	  (when (or (equal "ORG-BLOCKQUOTE-START" line)
+	  (when (or (and (equal "ORG-BLOCKQUOTE-START" line)
+			 (setq inblockquote t))
 		    (and (equal "ORG-VERSE-START" line)
 			 (setq inverse t)))
 	    (org-export-docbook-close-para-maybe)
@@ -742,6 +745,7 @@ publishing directory."
 
 	  ;; End of block quotes
 	  (when (equal "ORG-BLOCKQUOTE-END" line)
+	    (setq inblockquote nil)
 	    (org-export-docbook-close-para-maybe)
 	    (insert "</blockquote>\n")
 	    (org-export-docbook-open-para)
@@ -758,6 +762,7 @@ publishing directory."
 	  ;; seem to work with FOP, so for now we use <informaltable> to
 	  ;; center the text, which can contain multiple paragraphs.
 	  (when (equal "ORG-CENTER-START" line)
+	    (setq incenter t)
 	    (org-export-docbook-close-para-maybe)
 	    (insert "<informaltable frame=\"none\" colsep=\"0\" rowsep=\"0\">\n"
 		    "<tgroup align=\"center\" cols=\"1\">\n"
@@ -766,6 +771,7 @@ publishing directory."
 	    (throw 'nextline nil))
 
 	  (when (equal "ORG-CENTER-END" line)
+	    (setq incenter nil)
 	    (org-export-docbook-close-para-maybe)
 	    (insert "</entry></row></tbody>\n"
 		    "</tgroup>\n</informaltable>\n")
@@ -970,7 +976,10 @@ publishing directory."
 		    (push (cons num 1) footref-seen))))))
 
 	  (cond
-	   ((string-match "^\\(\\*+\\)[ \t]+\\(.*\\)" line)
+	   ((and (not incenter)
+		 (not inblockquote)
+		 (not inverse)
+		 (string-match "^\\(\\*+\\)[ \t]+\\(.*\\)" line))
 	    ;; This is a headline
 	    (setq level (org-tr-level (- (match-end 1) (match-beginning 1)
 					 level-offset))
diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index 08c0ac6..3b8c273 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -1655,7 +1655,12 @@ These special cookies will later be interpreted by the backend."
 			      content "\n"
 			      "ORG-" (upcase t1) "-END\n"))
 	(delete-region beg end)
-	(insert (org-add-props content nil 'original-indentation ind))))))
+	(insert (org-add-props content nil 'original-indentation ind))
+	;; Protect headings inside block
+	(goto-char beg)
+	(while (re-search-forward "^\\(\\*\\)+[ \t]+" end 'move)
+	  (add-text-properties
+	   (match-beginning 1) (match-end 1) '(org-protected t)))))))
 
 (defun org-export-mark-list-ending (backend)
   "Mark list endings with special cookies.
diff --git a/lisp/org-html.el b/lisp/org-html.el
index 1a3e673..9e5a268 100644
--- a/lisp/org-html.el
+++ b/lisp/org-html.el
@@ -916,9 +916,11 @@ PUB-DIR is set, use this as the publishing directory."
 	 (html-table-tag (plist-get opt-plist :html-table-tag))
 	 (quote-re0   (concat "^[ \t]*" org-quote-string "\\>"))
 	 (quote-re    (concat "^\\(\\*+\\)\\([ \t]+" org-quote-string "\\>\\)"))
-	 (inquote     nil)
-	 (infixed     nil)
-	 (inverse     nil)
+	 (inquote      nil)
+	 (inblockquote nil)
+	 (infixed      nil)
+	 (inverse      nil)
+	 (incenter     nil)
 	 (in-local-list nil)
 	 (local-list-type nil)
 	 (local-list-indent nil)
@@ -1236,11 +1238,13 @@ lang=\"%s\" xml:lang=\"%s\">
 
 	  ;; Blockquotes, verse, and center
 	  (when (equal "ORG-BLOCKQUOTE-START" line)
+	    (setq inblockquote t)
 	    (org-close-par-maybe)
 	    (insert "<blockquote>\n")
 	    (org-open-par)
 	    (throw 'nextline nil))
 	  (when (equal "ORG-BLOCKQUOTE-END" line)
+	    (setq inblockquote nil)
 	    (org-close-par-maybe)
 	    (insert "\n</blockquote>\n")
 	    (org-open-par)
@@ -1258,11 +1262,13 @@ lang=\"%s\" xml:lang=\"%s\">
 	    (setq inverse nil)
 	    (throw 'nextline nil))
 	  (when (equal "ORG-CENTER-START" line)
+	    (setq incenter t)
 	    (org-close-par-maybe)
 	    (insert "\n<div style=\"text-align: center\">")
 	    (org-open-par)
 	    (throw 'nextline nil))
 	  (when (equal "ORG-CENTER-END" line)
+	    (setq incenter nil)
 	    (org-close-par-maybe)
 	    (insert "\n</div>")
 	    (org-open-par)
@@ -1510,7 +1516,10 @@ lang=\"%s\" xml:lang=\"%s\">
 			 t t line))))))
 
 	  (cond
-	   ((string-match "^\\(\\*+\\)[ \t]+\\(.*\\)" line)
+	   ((and (not inverse)
+		 (not incenter)
+		 (not inblockquote)
+		 (string-match "^\\(\\*+\\)[ \t]+\\(.*\\)" line))
 	    ;; This is a headline
 	    (setq level (org-tr-level (- (match-end 1) (match-beginning 1)
 					 level-offset))
-- 
1.7.3.2


[-- Attachment #4: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Dan,

Dan Davison wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw-XMD5yJDbdMSQIYZ4X/+iSw@public.gmane.orgrg>
> writes:
>> Dan Davison wrote:
>>> In addition to the Org example, would you mind supplying a concise,
>>> explicit statement of what the putative bug is? With just the Org example
>>> on its own, the bug is implicit and I at least feel that I'm having to
>>> work hard to get there!
>
> What I was trying to say is that with bug reports it is helpful if the first
> one or two sentences of the email are a precise and brief statement of what
> is going wrong. Then the reader can decide if she wants to continue to the
> more detailed and discursive material.

OK. I didn't catch your paragraph. I will do add an abstract next time. I've
been so focused on trying to give out everything in order not to make one
loose his time by being complete, with examples just to evaluate to see the
problem, that I may overflow the boxes.

* TODO Sum up the problem in a couple of lines
  SCHEDULED: <Next time>

Thanks.

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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Nicolas,

Nicolas Goaziou wrote:
>>>>>> Sébastien Vauban writes:
>
>> I'd expect to see all the above passage from the email to be
>> uninterpreted. It is not acting that way.
>
> According to the manual, VERSE block only preserves line breaks and
> leading white spaces. Otherwise it is _normal_ formatting.

Thanks for answering "officially".


> Though, this raises an interesting question about lists.
>
> At the moment, by design, Org doesn't recognize lists inside blocks.
> While this is obviously the way to go in SRC EXAMPLE and COMMENT
> blocks, it isn't as clear with VERSE, CENTER and QUOTE.

I would separate VERSE from CENTER and QUOTE, because the 2 last don't respect
the linebreaks. They're not "verbatim" (defined, for me and for now, by the
latter sentence).


> In the case of VERSE, preserving leading white spaces cannot cooperate
> with list exporting. So I still think lists shouldn't be interpreted
> here and, as such, not recognized there either. On the other side, in
> CENTER and QUOTE blocks, Org may be able to understand them (they are
> correctly exported in those cases).
>
> I could make this distinction when I'll update list model. For now, I
> suggest using the first patch, which simply ignores lists in HTML and
> LaTeX when in a VERSE block.

Thanks. I can understand that this problem has been underspecified, hence the
unclearness of what's the right behavior to adopt for VERSE.

Though, I don't understand cases where we would like to preserve the
"verbatimness" of the linebreaks, but not of the lists, which is the case,
currently, for VERSE. Is there any useful use case for that?

For me, both should be supported together, whichever the environment, or none.


> There are some other problems with those blocks. You can, for example,
> replacing your bullets with stars, and export again. This will become
> headings in a verse environment. I could bet this wasn't intended.
> This is because text as the same column as VERSE block header is
> pasted in the temporary buffer at column 0. Items thus become
> headings. The second patch prevents headlines inside blocks from being
> interpreted.

Thanks a lot. I'll try to play with those later (in the evening?).

For the emails, what environment would you advice me to use in general?  The
patched VERSE, or back to EXAMPLE (distinguished from RESULT, since Eric's
patch to wrap the Org results)?

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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Eric,

"Eric Schulte" wrote:
> "Eric Schulte" <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> This would be useful for custom export of the proposed future babel
>> results block (which I promise I'll implement soon).
>
> An experimental patch implementing wrapping of results using a new
> "wrap" :results header argument is attached. Here is an example of its
> usage.
>
> ** introducing =wrap= header argument
> #+begin_src emacs-lisp :results wrap
>   (mapcar (lambda (el) (list el (+ 1 (* el el)))) (number-sequence 0 10))
> #+end_src
>
> #+results:
> #+BEGIN_RESULT
> |  0 |   1 |
> |  1 |   2 |
> |  2 |   5 |
> |  3 |  10 |
> |  4 |  17 |
> |  5 |  26 |
> |  6 |  37 |
> |  7 |  50 |
> |  8 |  65 |
> |  9 |  82 |
> | 10 | 101 |
> #+END_RESULT
>
> now indented
> - first
> - second
>   #+begin_src emacs-lisp :results wrap
>     "something else"
>   #+end_src
>
>   #+results:
>   #+BEGIN_RESULT
>   : something else
>   #+END_RESULT
>
> I haven't applied it directly to the repository because I fear it could have
> negative effects on the wrapping of results in HTML and LaTeX blocks, so if
> any brave souls could try this out over the next day or two and let me know
> how it works I'd then feel much more comfortable about dropping it into the
> core.

Tested it (yesterday) for HTML. Per-fect!  Thanks a lot... It's of great use.

Tried to test it (now) for LaTeX. Can't, for the same reason as described in:

   [[http://mid.gmane.org/80eiadw0dh.fsf%40missioncriticalit.com][Email from Sébastien Vauban: Debugger entered--Lisp error: ]]** TODO Debugger entered--Lisp error: (void-function -mode)
   [2010-11-22 Mon 21:48]

Though, already a couple of comments:

1. I guess there is one little typo in your patch:
   +	    (wrap "#+BEGIN_LaTe\n" "#+END_LaTeX"))
                               ^

2. Could you make the wrap on by default?

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

Re: Re: [Babel] Need for an extra literal block construct

[Eric Schulte]

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

Hi Seb,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

[...]
>
> Tested it (yesterday) for HTML. Per-fect!  Thanks a lot... It's of great use.
>

great, thanks for testing

>
> Tried to test it (now) for LaTeX. Can't, for the same reason as
> described in:
>
>    [[http://mid.gmane.org/80eiadw0dh.fsf%40missioncriticalit.com][Email from Sébastien Vauban: Debugger entered--Lisp error: ]]** TODO Debugger entered--Lisp error: (void-function -mode)
>    [2010-11-22 Mon 21:48]
>

After looking at this message I don't understand what the error is, are
you getting a "void-function -mode" error when exporting to LaTeX?  The
following exports fine to LaTeX for me w/o error.

** introducing =wrap= header argument
#+begin_src emacs-lisp :results wrap :exports both
  (mapcar (lambda (el) (list el (+ 1 (* el el)))) (number-sequence 0 10))
#+end_src

#+results:
#+BEGIN_RESULT
|  0 |   1 |
|  1 |   2 |
|  2 |   5 |
|  3 |  10 |
|  4 |  17 |
|  5 |  26 |
|  6 |  37 |
|  7 |  50 |
|  8 |  65 |
|  9 |  82 |
| 10 | 101 |
#+END_RESULT

now indented
- first
- second
  #+begin_src emacs-lisp :results wrap :exports both
    "something else"
  #+end_src

  #+results:
  #+BEGIN_RESULT
  : something else
  #+END_RESULT

>
> Though, already a couple of comments:
>
> 1. I guess there is one little typo in your patch:
>    +	    (wrap "#+BEGIN_LaTe\n" "#+END_LaTeX"))
>                                ^
>

Fixed version attached, Thanks

>
> 2. Could you make the wrap on by default?
>

No, but you can by adding (:results . "wrap") to
`org-babel-default-header-args' in your personal configuration.
Although I guess if this is turned on by default then there should be a
way to turn it off, either a "nowrap" header argument or a "plain"
header argument or something that would be on by default.

So do you think this could be applied to the core?  If not what changes
would you recommend?

Thanks -- Eric

>
> Best regards,
>   Seb


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-wrap-results-header-argument-wraps-code-block-result.patch --]
[-- Type: text/x-diff, Size: 5423 bytes --]

From e2589d43280164dbcb2e1d3b18ef6bf23ac99b6b Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 19 Nov 2010 16:04:59 -0700
Subject: [PATCH] "wrap" :results header argument wraps code block results

* lisp/ob.el (org-babel-insert-result): Responds to new "wrap" header
  argument.
  (org-babel-merge-params): Includes new "wrap" header argument in
  one of the results header argument exclusive groups.
---
 lisp/ob.el |   72 +++++++++++++++++++++++++++++------------------------------
 1 files changed, 35 insertions(+), 37 deletions(-)

diff --git a/lisp/ob.el b/lisp/ob.el
index 3689619..9feb0a6 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -1433,11 +1433,11 @@ code ---- the results are extracted in the syntax of the source
 	    (delete-region (point) (org-babel-result-end)))
 	   ((member "append" result-params)
 	    (goto-char (org-babel-result-end)) (setq beg (point)))
-	   ((member "prepend" result-params) ;; already there
-	    )))
+	   ((member "prepend" result-params)))) ; already there
 	(setq results-switches
 	      (if results-switches (concat " " results-switches) ""))
-	(cond
+	;; insert results based on type
+	(cond			     
 	 ;; do nothing for an empty result
 	 ((= (length result) 0))
 	 ;; insert a list if preferred
@@ -1449,6 +1449,7 @@ code ---- the results are extracted in the syntax of the source
 				 '(:splicep nil :istart "- " :iend "\n")))))
 	 ;; assume the result is a table if it's not a string
 	 ((not (stringp result))
+	  (goto-char beg)
 	  (insert (concat (orgtbl-to-orgtbl
 			   (if (or (eq 'hline (car result))
 				   (and (listp (car result))
@@ -1458,24 +1459,30 @@ code ---- the results are extracted in the syntax of the source
 	  (goto-char beg) (when (org-at-table-p) (org-table-align)))
 	 ((member "file" result-params)
 	  (insert result))
-	 ((member "html" result-params)
-	  (insert (format "#+BEGIN_HTML%s\n%s#+END_HTML\n"
-			  results-switches result)))
-	 ((member "latex" result-params)
-	  (insert (format "#+BEGIN_LaTeX%s\n%s#+END_LaTeX\n"
-			  results-switches result)))
-	 ((member "code" result-params)
-	  (insert (format "#+BEGIN_SRC %s%s\n%s#+END_SRC\n"
-			  (or lang "none") results-switches result)))
-	 ((member "org" result-params)
-	  (insert (format "#+BEGIN_SRC org\n%s#+END_SRC\n" result)))
-	 ((member "raw" result-params)
-	  (save-excursion (insert result)) (if (org-at-table-p) (org-cycle)))
-	 (t
-	  (org-babel-examplize-region
-	   (point) (progn (insert result) (point)) results-switches)))
-	;; possibly indent the results to match the #+results line
+	 (t (goto-char beg)
+	    (org-babel-examplize-region
+	     (point) (progn (insert result) (point)) results-switches)))
 	(setq end (if (listp result) (org-table-end) (point)))
+	;; possibly wrap result
+	(flet ((wrap (start finish)
+		     (goto-char beg) (insert start)
+		     (goto-char (+ (if (listp result) 0 (length start)) end))
+		     (insert finish) (setq end (point))))
+	  (cond
+	   ((member "html" result-params)
+	    (wrap "#+BEGIN_HTML\n" "#+END_HTML"))
+	   ((member "latex" result-params)
+	    (wrap "#+BEGIN_LaTeX\n" "#+END_LaTeX"))
+	   ((member "code" result-params)
+	    (wrap (format "#+BEGIN_SRC %s%s\n" (or lang "none") results-switches)
+		  "#+END_SRC"))
+	   ((member "org" result-params)
+	    (wrap "#+BEGIN_ORG\n" "#+END_ORG"))
+	   ((member "raw" result-params)
+	    (goto-char beg) (if (org-at-table-p) (org-cycle)))
+	   ((member "wrap" result-params)
+	    (wrap "#+BEGIN_RESULT\n" "#+END_RESULT"))))
+	;; possibly indent the results to match the #+results line
 	(when (and indent (> indent 0)
 		   ;; in this case `table-align' does the work for us
 		   (not (and (listp result)
@@ -1503,22 +1510,13 @@ code ---- the results are extracted in the syntax of the source
      ((org-at-table-p) (progn (goto-char (org-table-end)) (point)))
      ((org-in-item-p) (- (org-list-bottom-point) 1))
      (t
-      (let ((case-fold-search t))
-        (cond
-         ((looking-at "[ \t]*#\\+begin_latex")
-          (re-search-forward "[ \t]*#\\+end_latex" nil t)
-          (forward-line 1))
-         ((looking-at "[ \t]*#\\+begin_html")
-          (re-search-forward "[ \t]*#\\+end_html" nil t)
-          (forward-line 1))
-         ((looking-at "[ \t]*#\\+begin_example")
-          (re-search-forward "[ \t]*#\\+end_example" nil t)
-          (forward-line 1))
-         ((looking-at "[ \t]*#\\+begin_src")
-          (re-search-forward "[ \t]*#\\+end_src" nil t)
-          (forward-line 1))
-         (t (progn (while (looking-at "[ \t]*\\(: \\|\\[\\[\\)")
-                     (forward-line 1))))))
+      (let ((case-fold-search t)
+	    (blocks-re (regexp-opt
+			(list "latex" "html" "example" "src" "result"))))
+	(if (looking-at (concat "[ \t]*#\\+begin_" blocks-re))
+	    (re-search-forward (concat "[ \t]*#\\+end_" blocks-re) nil t)
+	  (while (looking-at "[ \t]*\\(: \\|\\[\\[\\)")
+	    (forward-line 1))))
       (point)))))
 
 (defun org-babel-result-to-file (result)
@@ -1570,7 +1568,7 @@ This takes into account some special considerations for certain
 parameters when merging lists."
   (let ((results-exclusive-groups
 	 '(("file" "list" "vector" "table" "scalar" "raw" "org"
-            "html" "latex" "code" "pp")
+            "html" "latex" "code" "pp" "wrap")
 	   ("replace" "silent" "append" "prepend")
 	   ("output" "value")))
 	(exports-exclusive-groups
-- 
1.7.0.4


[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: Re: [Babel] Need for an extra literal block construct

[Nicolas Goaziou]

Hello,

>>>>> Sébastien Vauban writes:

> Though, I don't understand cases where we would like to preserve the
> "verbatimness" of the linebreaks, but not of the lists, which is the
> case, currently, for VERSE. Is there any useful use case for that?

> For me, both should be supported together, whichever the
> environment, or none.

I'm not sure to understand what you have in mind here.

On a technical point, I fail to see how you can have both leading
white spaces preserved and lists interpreted, in a reasonable way.
Thus, as VERSE environment preserves those spaces, lists can only be
left uninterpreted there.

Perhaps what you are missing is a block where only line breaks are
verbatim. There's an export option to preserve them on the whole file
but not on a part of a document, AFAIK.

> For the emails, what environment would you advice me to use in
> general? The patched VERSE, or back to EXAMPLE (distinguished from
> RESULT, since Eric's patch to wrap the Org results)?

I think VERSE (patched) is better than EXAMPLE because you can still
benefit from text markup (and LaTeX snippets). Sadly, mails can
sometimes be, well, very distant from poetry...

Regards,

-- Nicolas

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Eric,

(will answer to the other posts later, need to go and rest)

"Eric Schulte" wrote:
> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Tested it (yesterday) for HTML. Per-fect!  Thanks a lot... It's of great use.
>
> great, thanks for testing

Confirmed.

>> Tried to test it (now) for LaTeX. Can't, for the same reason as
>> described in:
>>
>>    [[http://mid.gmane.org/80eiadw0dh.fsf%40missioncriticalit.com]]
>>    [2010-11-22 Mon 21:48]
>
> After looking at this message I don't understand what the error is, are
> you getting a "void-function -mode" error when exporting to LaTeX?  The
> following exports fine to LaTeX for me w/o error.

As David explained, it must be a bad interaction of the "src native
fontification". Solved by coming back to Org master, only applying your patch,
and staying (temporarily) in "no native fontification" mode.

>> Though, already a couple of comments:
>>
>> 1. I guess there is one little typo in your patch:
>>    +	    (wrap "#+BEGIN_LaTe\n" "#+END_LaTeX"))
>
> Fixed version attached, Thanks

Tested it. Works perfect... after, of course, defining a new environment,
such as (used for my test, after loading package =xcolor=):

#+begin_src latex
\newenvironment{RESULT}[0]%
{\color{green}}
{}
#+end_src

Only "glitch" is, when applying your patch:

#+begin_src sh
sva@MEDIACENTER:~/src/org-mode 0$ git apply 0001-wrap-results-header-argument-wraps-code-block-result.patch
0001-wrap-results-header-argument-wraps-code-block-result.patch:29: trailing whitespace.
        (cond
warning: 1 line adds whitespace errors.
#+end_src

There are, indeed, a couple of spaces and tabs after one of the 2 conds you
introduce in the patch. Why is it a problem (even if a warning only), I have
no idea?

>> 2. Could you make the wrap on by default?
>
> No

Why not?  Because one needs first to add a environment in LaTeX?  Other reasons?

> but you can by adding (:results . "wrap") to `org-babel-default-header-args'
> in your personal configuration.

OK.

> Although I guess if this is turned on by default then there should be a way
> to turn it off, either a "nowrap" header argument or a "plain" header
> argument or something that would be on by default.

This would certainly be useful at some point in time, yes.

> So do you think this could be applied to the core?  If not what changes
> would you recommend?

I vote for applying it to master.

Thanks a lot, once more!

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

Re: [Babel] Need for an extra literal block construct

[Sébastien Vauban]

Hi Nicolas,

Nicolas Goaziou wrote:
>>>>>> Sébastien Vauban writes:
>
>> Though, I don't understand cases where we would like to preserve the
>> "verbatimness" of the linebreaks, but not of the lists, which is the
>> case, currently, for VERSE. Is there any useful use case for that?
>>
>> For me, both should be supported together, whichever the
>> environment, or none.
>
> I'm not sure to understand what you have in mind here.
>
> On a technical point, I fail to see how you can have both leading
> white spaces preserved and lists interpreted, in a reasonable way.
> Thus, as VERSE environment preserves those spaces, lists can only be
> left uninterpreted there.
>
> Perhaps what you are missing is a block where only line breaks are
> verbatim. There's an export option to preserve them on the whole file
> but not on a part of a document, AFAIK.

I will try to rephrase my mind in a intelligible way, and you'll tell me if I
succeed doing so...

I meant, for me, there are only 2 useful options regarding a "block
environment" such as BLOCKQUOTE and VERSE:

- either, nothing is "interpreted"; that is, line breaks are preserved, and
  lists are preserved as well (outputted as they are written in the block)

- either, line breaks are not preserved, and lists are nicely formatted as
  lists, with nice bullets in HTML/PDF (customized in CSS or class file).

For me, as of now, I do not see a useful use case, where one would want to
have line breaks preserved (as written in the source block) *but* lists
interpreted (ie, not as written in the source block).

Am I clearer?

Am I right or wrong, with regard to your own experience?


>> For the emails, what environment would you advice me to use in
>> general? The patched VERSE, or back to EXAMPLE (distinguished from
>> RESULT, since Eric's patch to wrap the Org results)?
>
> I think VERSE (patched) is better than EXAMPLE because you can still
> benefit from text markup (and LaTeX snippets). Sadly, mails can
> sometimes be, well, very distant from poetry...

OK. I'll follow your advice, after testing your patch.

Thanks!

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

Re: Re: [Babel] Need for an extra literal block construct

[Nicolas Goaziou]

Hello,
>>>>> Sébastien Vauban writes:

> I meant, for me, there are only 2 useful options regarding a "block
> environment" such as BLOCKQUOTE and VERSE:

> - either, nothing is "interpreted"; that is, line breaks are
> preserved, and lists are preserved as well (outputted as they are
> written in the block)

This is EXAMPLE environment and, in a less drastic way, VERSE
(patched).

> - either, line breaks are not preserved, and lists are nicely
> formatted as lists, with nice bullets in HTML/PDF (customized in CSS
> or class file).

This is QUOTE environment, almost. Lists are correctly exported, but
not recognized in the Org buffer.

> For me, as of now, I do not see a useful use case, where one would
> want to have line breaks preserved (as written in the source block)
> *but* lists interpreted (ie, not as written in the source block).

I agree. So, if the patch for VERSE is good, what's left is to let Org
recognize lists in some predefined environments (namely CENTER and
QUOTE).

Regards,

-- Nicolas