* [babel] Environment around exported results @ 2010-09-16 15:16 Sébastien Vauban 2010-09-20 4:46 ` Eric Schulte 0 siblings, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-09-16 15:16 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [babel] Environment around exported results 2010-09-16 15:16 [babel] Environment around exported results Sébastien Vauban @ 2010-09-20 4:46 ` Eric Schulte 2010-09-20 19:10 ` Sébastien Vauban 0 siblings, 1 reply; 34+ messages in thread From: Eric Schulte @ 2010-09-20 4:46 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode 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... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [babel] Environment around exported results 2010-09-20 4:46 ` Eric Schulte @ 2010-09-20 19:10 ` Sébastien Vauban 2010-09-21 7:44 ` Sébastien Vauban 2010-09-21 13:14 ` Eric Schulte 0 siblings, 2 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-09-20 19:10 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [babel] Environment around exported results 2010-09-20 19:10 ` Sébastien Vauban @ 2010-09-21 7:44 ` Sébastien Vauban 2010-09-21 13:14 ` Eric Schulte 1 sibling, 0 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-09-21 7:44 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [babel] Environment around exported results 2010-09-20 19:10 ` Sébastien Vauban 2010-09-21 7:44 ` Sébastien Vauban @ 2010-09-21 13:14 ` Eric Schulte 2010-09-24 9:28 ` Sébastien Vauban 1 sibling, 1 reply; 34+ messages in thread From: Eric Schulte @ 2010-09-21 13:14 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [babel] Environment around exported results 2010-09-21 13:14 ` Eric Schulte @ 2010-09-24 9:28 ` Sébastien Vauban 2010-09-24 21:01 ` Rainer M Krug 0 siblings, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-09-24 9:28 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [babel] Environment around exported results 2010-09-24 9:28 ` Sébastien Vauban @ 2010-09-24 21:01 ` Rainer M Krug 2010-09-27 8:16 ` Sébastien Vauban 0 siblings, 1 reply; 34+ messages in thread From: Rainer M Krug @ 2010-09-24 21:01 UTC (permalink / raw) To: Eric Schulte; +Cc: Sébastien Vauban, emacs-orgmode -----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----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [babel] Environment around exported results 2010-09-24 21:01 ` Rainer M Krug @ 2010-09-27 8:16 ` Sébastien Vauban 2010-11-19 13:27 ` [Babel] Need for an extra literal block construct Sébastien Vauban 0 siblings, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-09-27 8:16 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [Babel] Need for an extra literal block construct 2010-09-27 8:16 ` Sébastien Vauban @ 2010-11-19 13:27 ` Sébastien Vauban 2010-11-19 15:17 ` Christian Moe 0 siblings, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-11-19 13:27 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 13:27 ` [Babel] Need for an extra literal block construct Sébastien Vauban @ 2010-11-19 15:17 ` Christian Moe 2010-11-19 20:12 ` Sébastien Vauban 0 siblings, 1 reply; 34+ messages in thread From: Christian Moe @ 2010-11-19 15:17 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 15:17 ` Christian Moe @ 2010-11-19 20:12 ` Sébastien Vauban 2010-11-19 20:26 ` Sébastien Vauban ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-19 20:12 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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">>> 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 </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"> >> Does it work?<br/> ><br/> > Yes, if you:<br/> > - update <code>this-var</code><br/> > - 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 20:12 ` Sébastien Vauban @ 2010-11-19 20:26 ` Sébastien Vauban 2010-11-19 20:38 ` Thomas S. Dye 2010-11-19 22:24 ` Eric Schulte 2010-11-19 22:36 ` Dan Davison 2010-11-19 23:10 ` Christian Moe 2 siblings, 2 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-19 20:26 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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"> > >> Does it work?<br/> > ><br/> > > Yes, if you:<br/> > > > - update <code>this-var</code><br/> > > - 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-19 20:26 ` Sébastien Vauban @ 2010-11-19 20:38 ` Thomas S. Dye 2010-11-19 22:02 ` Sébastien Vauban 2010-11-19 22:24 ` Eric Schulte 1 sibling, 1 reply; 34+ messages in thread From: Thomas S. Dye @ 2010-11-19 20:38 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode 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"> >> >> Does it work?<br/> >> ><br/> >> > Yes, if you:<br/> >> >> > - update <code>this-var</code><br/> >> > - 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 20:38 ` Thomas S. Dye @ 2010-11-19 22:02 ` Sébastien Vauban 2010-11-19 22:20 ` Thomas S. Dye 0 siblings, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-11-19 22:02 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-19 22:02 ` Sébastien Vauban @ 2010-11-19 22:20 ` Thomas S. Dye 2010-11-19 23:00 ` Sébastien Vauban 0 siblings, 1 reply; 34+ messages in thread From: Thomas S. Dye @ 2010-11-19 22:20 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 22:20 ` Thomas S. Dye @ 2010-11-19 23:00 ` Sébastien Vauban 0 siblings, 0 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-19 23:00 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-19 20:26 ` Sébastien Vauban 2010-11-19 20:38 ` Thomas S. Dye @ 2010-11-19 22:24 ` Eric Schulte 2010-11-19 23:07 ` Eric Schulte 2010-11-19 23:13 ` Sébastien Vauban 1 sibling, 2 replies; 34+ messages in thread From: Eric Schulte @ 2010-11-19 22:24 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-19 22:24 ` Eric Schulte @ 2010-11-19 23:07 ` Eric Schulte 2010-11-20 7:20 ` Sébastien Vauban 2010-11-22 21:46 ` Sébastien Vauban 2010-11-19 23:13 ` Sébastien Vauban 1 sibling, 2 replies; 34+ messages in thread From: Eric Schulte @ 2010-11-19 23:07 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 23:07 ` Eric Schulte @ 2010-11-20 7:20 ` Sébastien Vauban 2010-11-22 21:46 ` Sébastien Vauban 1 sibling, 0 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-20 7:20 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 23:07 ` Eric Schulte 2010-11-20 7:20 ` Sébastien Vauban @ 2010-11-22 21:46 ` Sébastien Vauban 2010-11-23 0:42 ` Eric Schulte 1 sibling, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-11-22 21:46 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-22 21:46 ` Sébastien Vauban @ 2010-11-23 0:42 ` Eric Schulte 2010-11-23 23:15 ` Sébastien Vauban 0 siblings, 1 reply; 34+ messages in thread From: Eric Schulte @ 2010-11-23 0:42 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-23 0:42 ` Eric Schulte @ 2010-11-23 23:15 ` Sébastien Vauban 0 siblings, 0 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-23 23:15 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 22:24 ` Eric Schulte 2010-11-19 23:07 ` Eric Schulte @ 2010-11-19 23:13 ` Sébastien Vauban 1 sibling, 0 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-19 23:13 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 20:12 ` Sébastien Vauban 2010-11-19 20:26 ` Sébastien Vauban @ 2010-11-19 22:36 ` Dan Davison 2010-11-20 21:50 ` Sébastien Vauban 2010-11-19 23:10 ` Christian Moe 2 siblings, 1 reply; 34+ messages in thread From: Dan Davison @ 2010-11-19 22:36 UTC (permalink / raw) To: Sébastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ 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">>> 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 > </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"> > >> Does it work?<br/> > ><br/> > > Yes, if you:<br/> > > > - update <code>this-var</code><br/> > > - 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 22:36 ` Dan Davison @ 2010-11-20 21:50 ` Sébastien Vauban 2010-11-21 10:01 ` Dan Davison 2010-11-21 13:41 ` Nicolas Goaziou 0 siblings, 2 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-20 21:50 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ [-- 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-20 21:50 ` Sébastien Vauban @ 2010-11-21 10:01 ` Dan Davison 2010-11-22 20:22 ` Sébastien Vauban 2010-11-21 13:41 ` Nicolas Goaziou 1 sibling, 1 reply; 34+ messages in thread From: Dan Davison @ 2010-11-21 10:01 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs org-mode mailing list 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-21 10:01 ` Dan Davison @ 2010-11-22 20:22 ` Sébastien Vauban 0 siblings, 0 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-22 20:22 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-20 21:50 ` Sébastien Vauban 2010-11-21 10:01 ` Dan Davison @ 2010-11-21 13:41 ` Nicolas Goaziou 2010-11-22 20:30 ` Sébastien Vauban 1 sibling, 1 reply; 34+ messages in thread From: Nicolas Goaziou @ 2010-11-21 13:41 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-21 13:41 ` Nicolas Goaziou @ 2010-11-22 20:30 ` Sébastien Vauban 2010-11-23 19:27 ` Nicolas Goaziou 0 siblings, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-11-22 20:30 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-22 20:30 ` Sébastien Vauban @ 2010-11-23 19:27 ` Nicolas Goaziou 2010-11-23 23:22 ` Sébastien Vauban 0 siblings, 1 reply; 34+ messages in thread From: Nicolas Goaziou @ 2010-11-23 19:27 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-23 19:27 ` Nicolas Goaziou @ 2010-11-23 23:22 ` Sébastien Vauban 2010-11-24 10:14 ` Nicolas Goaziou 0 siblings, 1 reply; 34+ messages in thread From: Sébastien Vauban @ 2010-11-23 23:22 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-23 23:22 ` Sébastien Vauban @ 2010-11-24 10:14 ` Nicolas Goaziou 0 siblings, 0 replies; 34+ messages in thread From: Nicolas Goaziou @ 2010-11-24 10:14 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Re: [Babel] Need for an extra literal block construct 2010-11-19 20:12 ` Sébastien Vauban 2010-11-19 20:26 ` Sébastien Vauban 2010-11-19 22:36 ` Dan Davison @ 2010-11-19 23:10 ` Christian Moe 2010-11-19 23:23 ` Sébastien Vauban 2 siblings, 1 reply; 34+ messages in thread From: Christian Moe @ 2010-11-19 23:10 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode 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">>> 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 > </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"> > >> Does it work?<br/> > ><br/> > > Yes, if you:<br/> > > > - update<code>this-var</code><br/> > > - 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 > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [Babel] Need for an extra literal block construct 2010-11-19 23:10 ` Christian Moe @ 2010-11-19 23:23 ` Sébastien Vauban 0 siblings, 0 replies; 34+ messages in thread From: Sébastien Vauban @ 2010-11-19 23:23 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2010-11-24 10:18 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-16 15:16 [babel] Environment around exported results Sébastien Vauban 2010-09-20 4:46 ` Eric Schulte 2010-09-20 19:10 ` Sébastien Vauban 2010-09-21 7:44 ` Sébastien Vauban 2010-09-21 13:14 ` Eric Schulte 2010-09-24 9:28 ` Sébastien Vauban 2010-09-24 21:01 ` Rainer M Krug 2010-09-27 8:16 ` Sébastien Vauban 2010-11-19 13:27 ` [Babel] Need for an extra literal block construct Sébastien Vauban 2010-11-19 15:17 ` Christian Moe 2010-11-19 20:12 ` Sébastien Vauban 2010-11-19 20:26 ` Sébastien Vauban 2010-11-19 20:38 ` Thomas S. Dye 2010-11-19 22:02 ` Sébastien Vauban 2010-11-19 22:20 ` Thomas S. Dye 2010-11-19 23:00 ` Sébastien Vauban 2010-11-19 22:24 ` Eric Schulte 2010-11-19 23:07 ` Eric Schulte 2010-11-20 7:20 ` Sébastien Vauban 2010-11-22 21:46 ` Sébastien Vauban 2010-11-23 0:42 ` Eric Schulte 2010-11-23 23:15 ` Sébastien Vauban 2010-11-19 23:13 ` Sébastien Vauban 2010-11-19 22:36 ` Dan Davison 2010-11-20 21:50 ` Sébastien Vauban 2010-11-21 10:01 ` Dan Davison 2010-11-22 20:22 ` Sébastien Vauban 2010-11-21 13:41 ` Nicolas Goaziou 2010-11-22 20:30 ` Sébastien Vauban 2010-11-23 19:27 ` Nicolas Goaziou 2010-11-23 23:22 ` Sébastien Vauban 2010-11-24 10:14 ` Nicolas Goaziou 2010-11-19 23:10 ` Christian Moe 2010-11-19 23:23 ` Sébastien Vauban
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).