Nick Dokos <nicholas.do...@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/