BUG: example/src blocks and latex export

BUG: example/src blocks and latex export

[Nick Dokos]

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

Consider the following org file:

--8<---------------cut here---------------start------------->8---

* foo

Verbiage to begin the paragraph
#+begin_src shell
get-config.py var section [section ...]
#+end_src
and verbiage to end the same paragraph.

* bar

Verbiage to begin the paragraph
#+begin_example
get-config.py var section [section ...]
#+end_example
and verbiage to end the same paragraph.
--8<---------------cut here---------------end--------------->8---


When exported to latex with current git (Org-mode version 7.7 (release_7.7.120.g2edd.dirty)),
I get:

--8<---------------cut here---------------start------------->8---
Verbiage to begin the paragraph

\begin{verbatim}
get-config.py var section [section ...]
\end{verbatim}



and verbiage to end the same paragraph.
\section{bar}
\label{sec-2}


Verbiage to begin the paragraph

\begin{verbatim}
get-config.py var section [section ...]
\end{verbatim}


and verbiage to end the same paragraph.
--8<---------------cut here---------------end--------------->8---

so both instances of "verbiage to end the same paragraph" actually end
up being in a different paragraph, with three empty lines after a
source block and two empty lines after an example block, where none
existed before.  LaTeX indents the newly created paragraph and it
looks ugly. Of course, just a single empty line is enough to do
the damage, but the fact that there is more than one and that there
are different numbers, indicates multiple places where a gratuitous
newline is inserted.

I get sane behavior with the attached patch, but I'm wondering if it
breaks other backends, so if somebody is willing to test, I'd appreciate
it (and of course, I'll test as well). For the time being at least, this
is a trial balloon, not a real patch.

ISTR this issue coming up on the list recently: did I imagine it?  If
not, could somebody provide a reference? My feeble attempts at searching
gmane were unsuccessful. I did find an old thread between Nicolas Girard
and Carsten and apparently things were fine for a while. Or I may be
thinking about Tom Dye's problem with lists embedded in a paragraph.
about a month ago, but this is a different problem.

Thanks,
Nick


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH} Eliminate extra newline(s) after example or src block. --]
[-- Type: text/x-lisp, Size: 2062 bytes --]

From b267aacef1e767cf6ba6d0d9aa8cb4109c7685d3 Mon Sep 17 00:00:00 2001
From: Nick Dokos <nick@dokosmarshall.org>
Date: Fri, 19 Aug 2011 05:02:57 -0400
Subject: [PATCH] Eliminate extra newline(s) after example or src block.


Signed-off-by: Nick Dokos <nick@dokosmarshall.org>
---
 lisp/ob-exp.el    |    2 +-
 lisp/org-exp.el   |    2 +-
 lisp/org-latex.el |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 9da0487..d1b13c8 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -231,7 +231,7 @@ The function respects the value of the :exports header argument."
 (defun org-babel-exp-code (info)
   "Return the original code block formatted for export."
   (org-fill-template
-   "#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC\n"
+   "#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC"
    `(("lang"  . ,(nth 0 info))
      ("flags" . ,((lambda (f) (when f (concat " " f))) (nth 3 info)))
      ("body"  . ,(nth 1 info)))))
diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index 740f195..a2a2fb3 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -2718,7 +2718,7 @@ INDENT was the original indentation of the block."
 	     "\n#+BEGIN_" backend-name "\n"
 	     (org-add-props rtn
 		 '(org-protected t org-example t org-native-text t))
-	     "\n#+END_" backend-name "\n\n"))
+	     "\n#+END_" backend-name "\n"))
       (org-add-props rtn nil 'original-indentation indent))))
 
 (defun org-export-number-lines (text &optional skip1 skip2 number cont
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index f46f9f5..17626b5 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -401,7 +401,7 @@ will pass them (combined with the LaTeX default list parameters) to
   :type 'plist)
 
 (defcustom org-export-latex-verbatim-wrap
-  '("\\begin{verbatim}\n" . "\\end{verbatim}\n")
+  '("\\begin{verbatim}\n" . "\\end{verbatim}")
   "Environment to be wrapped around a fixed-width section in LaTeX export.
 This is a cons with two strings, to be added before and after the
 fixed-with text.
-- 
1.7.5.1.169.g505a1

Re: BUG: example/src blocks and latex export

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Consider the following org file:
>
>
> * foo
>
> Verbiage to begin the paragraph
> #+begin_src shell
> get-config.py var section [section ...]
> #+end_src
> and verbiage to end the same paragraph.
>
> * bar
>
> Verbiage to begin the paragraph
> #+begin_example
> get-config.py var section [section ...]
> #+end_example
> and verbiage to end the same paragraph.
>
>
> When exported to latex with current git (Org-mode version 7.7 (release_7.7.120.g2edd.dirty)),
> I get:
>
> Verbiage to begin the paragraph
>
> \begin{verbatim}
> get-config.py var section [section ...]
> \end{verbatim}
>
>
>
> and verbiage to end the same paragraph.
> \section{bar}
> \label{sec-2}
>
>
> Verbiage to begin the paragraph
>
> \begin{verbatim}
> get-config.py var section [section ...]
> \end{verbatim}
>
>
> and verbiage to end the same paragraph.
>
> so both instances of "verbiage to end the same paragraph" actually end
> up being in a different paragraph, with three empty lines after a
> source block and two empty lines after an example block, where none
> existed before.  LaTeX indents the newly created paragraph and it
> looks ugly. Of course, just a single empty line is enough to do
> the damage, but the fact that there is more than one and that there
> are different numbers, indicates multiple places where a gratuitous
> newline is inserted.
>

If you want results embedded into a paragraph, then I would suggest
using an inline code block.  Regular code blocks are "blocks" in that
they will break paragraphs and are treated (in my mind) more like
figures than inline elements.

>
> I get sane behavior with the attached patch, but I'm wondering if it
> breaks other backends, so if somebody is willing to test, I'd appreciate
> it (and of course, I'll test as well). For the time being at least, this
> is a trial balloon, not a real patch.
>

Thanks for the patch, I would not want this behavior on by default
because I think the results in the Org-mode file are less visually
pleasing than when results are padded with spaces.  Perhaps this
behavior could be controlled through a new header argument which would
default to the current behavior.

> ISTR this issue coming up on the list recently: did I imagine it?

A similar issue regarding the insertion of spaces through repeated
evaluation and removal of results of a code block has been discussed
recently.  I'm pushing up a small fix for that issue now.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: BUG: example/src blocks and latex export

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> If you want results embedded into a paragraph, then I would suggest
> using an inline code block.  Regular code blocks are "blocks" in that
> they will break paragraphs and are treated (in my mind) more like
> figures than inline elements.
> 

Actually in my "real" case, I was using ``:exports code'' in a #+BABEL
header, but I forgot to include that in the test.

> >
> > I get sane behavior with the attached patch, but I'm wondering if it
> > breaks other backends, so if somebody is willing to test, I'd appreciate
> > it (and of course, I'll test as well). For the time being at least, this
> > is a trial balloon, not a real patch.
> >
> 
> Thanks for the patch, I would not want this behavior on by default
> because I think the results in the Org-mode file are less visually
> pleasing than when results are padded with spaces.  Perhaps this
> behavior could be controlled through a new header argument which would
> default to the current behavior.
> 

OK - I did not test evaluation at all: thanks for reminding me.

> > ISTR this issue coming up on the list recently: did I imagine it?
> 
> A similar issue regarding the insertion of spaces through repeated
> evaluation and removal of results of a code block has been discussed
> recently.  I'm pushing up a small fix for that issue now.
> 

I'll keep an eye out for it.

Thanks,
Nick

Re: BUG: example/src blocks and latex export

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> > I get sane behavior with the attached patch, but I'm wondering if it
> > breaks other backends, so if somebody is willing to test, I'd appreciate
> > it (and of course, I'll test as well). For the time being at least, this
> > is a trial balloon, not a real patch.
> >
> 
> Thanks for the patch, I would not want this behavior on by default
> because I think the results in the Org-mode file are less visually
> pleasing than when results are padded with spaces.  Perhaps this
> behavior could be controlled through a new header argument which would
> default to the current behavior.
> 

I tried evaluating the code block in the following file both with (my
probably slightly stale version of) master: Org-mode version 7.7
(release_7.7.120.g2edd) and the version with the patch applied: Org-mode
version 7.7 (release_7.7.121.gb267a)

--8<---------------cut here---------------start------------->8---
#+BABEL: :exports code

* foo

Verbiage to begin the paragraph
#+begin_src sh
date
#+end_src
and verbiage to end the same paragraph.

* bar

Verbiage to begin the paragraph
#+begin_example
date
#+end_example
and verbiage to end the same paragraph.
--8<---------------cut here---------------end--------------->8---

After C-c C-c in the code block, it looks like this in both cases:

--8<---------------cut here---------------start------------->8---
#+BABEL: :exports code

* foo

Verbiage to begin the paragraph
#+begin_src sh
date
#+end_src

#+results:
: Fri Aug 19 15:36:04 EDT 2011

and verbiage to end the same paragraph.

* bar

Verbiage to begin the paragraph
#+begin_example
date
#+end_example
and verbiage to end the same paragraph.
--8<---------------cut here---------------end--------------->8---

So I don't think the patch changes anything in the visual appearance of
the results. Am I missing something? Were you worried about this or
something else? Of course, the line after the results does become a new
paragraph in this case when exported to latex: there's yet *another*
newline inserted after the results, but that is a separate problem, and
the patch under discussion does not change that behavior at all.
Agreed?

Thanks,
Nick

Re: BUG: example/src blocks and latex export

[Bastien]

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> * foo
>
> Verbiage to begin the paragraph
> #+begin_src shell
> get-config.py var section [section ...]
> #+end_src
> and verbiage to end the same paragraph.
>
> * bar
>
> Verbiage to begin the paragraph
> #+begin_example
> get-config.py var section [section ...]
> #+end_example
> and verbiage to end the same paragraph.

I tested your patch with the example above and I get this:

,----
| Verbiage to begin the paragraph
| 
| \lstset{language=shell}
| \begin{lstlisting}
| get-config.py var section [section ...]
| \end{lstlisting}
| 
| and verbiage to end the same paragraph.
| \section*{bar}
| \label{sec-2}
| 
| 
| Verbiage to begin the paragraph
| 
| \begin{verbatim}
| get-config.py var section [section ...]
| \end{verbatim}
| and verbiage to end the same paragraph.
`----

It looks better than the current export (less white lines) but still
has a problem with the first "and verbiage..." being indented.

Is this intentional?  Or do you want the same behavior for #+begin_src
and #+begin_example?

In overall, I think number of white lines should be the same in the Org
source file and in the LaTeX exported file, so a patch here is welcome.
But maybe I misunderstood something in Eric's reply.

Thanks,

-- 
 Bastien

Re: BUG: example/src blocks and latex export

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi Nick,
> 
> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > * foo
> >
> > Verbiage to begin the paragraph
> > #+begin_src shell
> > get-config.py var section [section ...]
> > #+end_src
> > and verbiage to end the same paragraph.
> >
> > * bar
> >
> > Verbiage to begin the paragraph
> > #+begin_example
> > get-config.py var section [section ...]
> > #+end_example
> > and verbiage to end the same paragraph.
> 
> I tested your patch with the example above and I get this:
> 
> ,----
> | Verbiage to begin the paragraph
> | 
> | \lstset{language=shell}
> | \begin{lstlisting}
> | get-config.py var section [section ...]
> | \end{lstlisting}
> | 
> | and verbiage to end the same paragraph.
> | \section*{bar}
> | \label{sec-2}
> | 
> | 
> | Verbiage to begin the paragraph
> | 
> | \begin{verbatim}
> | get-config.py var section [section ...]
> | \end{verbatim}
> | and verbiage to end the same paragraph.
> `----
> 
> It looks better than the current export (less white lines) but still
> has a problem with the first "and verbiage..." being indented.
> 
> Is this intentional?  Or do you want the same behavior for #+begin_src
> and #+begin_example?
> 

Not intentional. But I have org-export-latex-listings set to nil, so in
my case, the src block gets turned into a verbatim environment, not into
a listings environment, and there is no empty line there.  Let me play
around a bit with org-export-latex-listings and see.

I guess the change in org-latex-verbatim-wrap takes care of my case,
but there is another (gratuitous?) newline inserted after listings.

> In overall, I think number of white lines should be the same in the
> Org source file and in the LaTeX exported file, so a patch here is
> welcome.  But maybe I misunderstood something in Eric's reply.

I tend to agree, but I can also understand Eric's wish for visual
separation.  However, as I pointed out in my earlier reply to him, I
think that's a separate problem, not addressed (or affected) by this
patch.

Thanks for testing,
Nick

Re: BUG: example/src blocks and latex export

[Nick Dokos]

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

Bastien <bzg@altern.org> wrote:

> Hi Nick,
> 
> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > * foo
> >
> > Verbiage to begin the paragraph
> > #+begin_src shell
> > get-config.py var section [section ...]
> > #+end_src
> > and verbiage to end the same paragraph.
> >
> > * bar
> >
> > Verbiage to begin the paragraph
> > #+begin_example
> > get-config.py var section [section ...]
> > #+end_example
> > and verbiage to end the same paragraph.
> 
> I tested your patch with the example above and I get this:
> 
> ,----
> | Verbiage to begin the paragraph
> | 
> | \lstset{language=shell}
> | \begin{lstlisting}
> | get-config.py var section [section ...]
> | \end{lstlisting}
> | 
> | and verbiage to end the same paragraph.
> | \section*{bar}
> | \label{sec-2}
> | 
> | 
> | Verbiage to begin the paragraph
> | 
> | \begin{verbatim}
> | get-config.py var section [section ...]
> | \end{verbatim}
> | and verbiage to end the same paragraph.
> `----
> 
> It looks better than the current export (less white lines) but still
> has a problem with the first "and verbiage..." being indented.
> 
> Is this intentional?  Or do you want the same behavior for #+begin_src
> and #+begin_example?
> 
> In overall, I think number of white lines should be the same in the Org
> source file and in the LaTeX exported file, so a patch here is welcome.
> But maybe I misunderstood something in Eric's reply.
> 

So here's another patch to get rid of some more newlines, these ones after
a listings or minted environment. I tried both with the previously posted file
and setting org-export-latex-listings to t or 'minted. AFAICT, it works as it
should and should not break anything else, but... This is to be applied on top
of the previous one (and it's still very much a trial balloon).

BTW, the defcustom of org-export-latex-listings seems to be outdated:
custom thinks it's a boolean, but it can now take at least one more value
(minted - see the docstring).

Thanks,
Nick


[-- Attachment #2: [PATCH 2/2] Get rid of gratuitous newline after listing/minted --]
[-- Type: text/plain, Size: 1094 bytes --]

From 5337cbb0669c6b05170190ec1e5751bdcf132d87 Mon Sep 17 00:00:00 2001
From: Nick Dokos <nick@dokosmarshall.org>
Date: Fri, 19 Aug 2011 18:36:50 -0400
Subject: [PATCH 2/2] Get rid of gratuitous newline after listing/minted
 environment.


Signed-off-by: Nick Dokos <nick@dokosmarshall.org>
---
 lisp/org-exp.el |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index a2a2fb3..f795fbd 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -2689,11 +2689,11 @@ INDENT was the original indentation of the block."
 		       (format "\\begin{%s}\n%s\\end{%s}\n"
 			       custom-environment rtn custom-environment))
 		      (listings-p
-		       (format "\\begin{%s}\n%s\\end{%s}\n"
+		       (format "\\begin{%s}\n%s\\end{%s}"
 			       "lstlisting" rtn "lstlisting"))
 		      (minted-p
 		       (format
-			"\\begin{minted}[%s]{%s}\n%s\\end{minted}\n"
+			"\\begin{minted}[%s]{%s}\n%s\\end{minted}"
 			(mapconcat #'make-option-string
 				   org-export-latex-minted-options ",")
 			backend-lang rtn)))))))
-- 
1.7.5.1.169.g505a1

Re: BUG: example/src blocks and latex export

[Eric Schulte]

Bastien <bzg@altern.org> writes:

> Hi Nick,
>
> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> * foo
>>
>> Verbiage to begin the paragraph
>> #+begin_src shell
>> get-config.py var section [section ...]
>> #+end_src
>> and verbiage to end the same paragraph.
>>
>> * bar
>>
>> Verbiage to begin the paragraph
>> #+begin_example
>> get-config.py var section [section ...]
>> #+end_example
>> and verbiage to end the same paragraph.
>
> I tested your patch with the example above and I get this:
>
> ,----
> | Verbiage to begin the paragraph
> | 
> | \lstset{language=shell}
> | \begin{lstlisting}
> | get-config.py var section [section ...]
> | \end{lstlisting}
> | 
> | and verbiage to end the same paragraph.
> | \section*{bar}
> | \label{sec-2}
> | 
> | 
> | Verbiage to begin the paragraph
> | 
> | \begin{verbatim}
> | get-config.py var section [section ...]
> | \end{verbatim}
> | and verbiage to end the same paragraph.
> `----
>
> It looks better than the current export (less white lines) but still
> has a problem with the first "and verbiage..." being indented.
>
> Is this intentional?  Or do you want the same behavior for #+begin_src
> and #+begin_example?
>
> In overall, I think number of white lines should be the same in the Org
> source file and in the LaTeX exported file, so a patch here is welcome.
> But maybe I misunderstood something in Eric's reply.
>

I had misread Nicks first email and thus my reply made no sense.  I've
applied this patch as it seems to be a definite improvement.

Thanks! -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: BUG: example/src blocks and latex export

[Eric Schulte]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Bastien <bzg@altern.org> wrote:
>
>> Hi Nick,
>> 
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>> 
>> > * foo
>> >
>> > Verbiage to begin the paragraph
>> > #+begin_src shell
>> > get-config.py var section [section ...]
>> > #+end_src
>> > and verbiage to end the same paragraph.
>> >
>> > * bar
>> >
>> > Verbiage to begin the paragraph
>> > #+begin_example
>> > get-config.py var section [section ...]
>> > #+end_example
>> > and verbiage to end the same paragraph.
>> 
>> I tested your patch with the example above and I get this:
>> 
>> ,----
>> | Verbiage to begin the paragraph
>> | 
>> | \lstset{language=shell}
>> | \begin{lstlisting}
>> | get-config.py var section [section ...]
>> | \end{lstlisting}
>> | 
>> | and verbiage to end the same paragraph.
>> | \section*{bar}
>> | \label{sec-2}
>> | 
>> | 
>> | Verbiage to begin the paragraph
>> | 
>> | \begin{verbatim}
>> | get-config.py var section [section ...]
>> | \end{verbatim}
>> | and verbiage to end the same paragraph.
>> `----
>> 
>> It looks better than the current export (less white lines) but still
>> has a problem with the first "and verbiage..." being indented.
>> 
>> Is this intentional?  Or do you want the same behavior for #+begin_src
>> and #+begin_example?
>> 
>> In overall, I think number of white lines should be the same in the Org
>> source file and in the LaTeX exported file, so a patch here is welcome.
>> But maybe I misunderstood something in Eric's reply.
>> 
>
> So here's another patch to get rid of some more newlines, these ones after
> a listings or minted environment. I tried both with the previously posted file
> and setting org-export-latex-listings to t or 'minted. AFAICT, it works as it
> should and should not break anything else, but... This is to be applied on top
> of the previous one (and it's still very much a trial balloon).
>

This seems like a logical extension of the previous patch, I've just
applied this as well.

Thanks Again -- Eric

>
> BTW, the defcustom of org-export-latex-listings seems to be outdated:
> custom thinks it's a boolean, but it can now take at least one more value
> (minted - see the docstring).
>
> Thanks,
> Nick
>
> From 5337cbb0669c6b05170190ec1e5751bdcf132d87 Mon Sep 17 00:00:00 2001
> From: Nick Dokos <nick@dokosmarshall.org>
> Date: Fri, 19 Aug 2011 18:36:50 -0400
> Subject: [PATCH 2/2] Get rid of gratuitous newline after listing/minted
>  environment.
>
>
> Signed-off-by: Nick Dokos <nick@dokosmarshall.org>
> ---
>  lisp/org-exp.el |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org-exp.el b/lisp/org-exp.el
> index a2a2fb3..f795fbd 100644
> --- a/lisp/org-exp.el
> +++ b/lisp/org-exp.el
> @@ -2689,11 +2689,11 @@ INDENT was the original indentation of the block."
>  		       (format "\\begin{%s}\n%s\\end{%s}\n"
>  			       custom-environment rtn custom-environment))
>  		      (listings-p
> -		       (format "\\begin{%s}\n%s\\end{%s}\n"
> +		       (format "\\begin{%s}\n%s\\end{%s}"
>  			       "lstlisting" rtn "lstlisting"))
>  		      (minted-p
>  		       (format
> -			"\\begin{minted}[%s]{%s}\n%s\\end{minted}\n"
> +			"\\begin{minted}[%s]{%s}\n%s\\end{minted}"
>  			(mapconcat #'make-option-string
>  				   org-export-latex-minted-options ",")
>  			backend-lang rtn)))))))

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/