From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: [BUG] inline source breaks paragraphs Date: Sat, 14 Dec 2013 12:53:15 +0100 Message-ID: <87wqj7lkd0.fsf@med.uni-goettingen.de> References: <87mwkb7ziz.fsf@med.uni-goettingen.de> <877gb87a1u.fsf@gmail.com> <87sitwcor6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vrnmu-0001fw-N1 for emacs-orgmode@gnu.org; Sat, 14 Dec 2013 06:53:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vrnmo-0006t4-Lt for emacs-orgmode@gnu.org; Sat, 14 Dec 2013 06:53:40 -0500 Received: from plane.gmane.org ([80.91.229.3]:59506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vrnmo-0006t0-BQ for emacs-orgmode@gnu.org; Sat, 14 Dec 2013 06:53:34 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vrnmj-0004Xo-3Z for emacs-orgmode@gnu.org; Sat, 14 Dec 2013 12:53:29 +0100 Received: from vpn-2093.gwdg.de ([134.76.2.93]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Dec 2013 12:53:29 +0100 Received: from andreas.leha by vpn-2093.gwdg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Dec 2013 12:53:29 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi, Eric Schulte writes: > Nicolas Goaziou writes: > >> Hello, >> >> Andreas Leha writes: >> >>> inline source -- when on its own line -- breaks the paragraph, which is >>> unexpected. >>> >>> Here is a test file: >>> >>> * Test >>> >>> This is a broken >>> src_R[:exports results :results raw]{10} >>> paragraph. >>> >>> >>> Here is (the relevant part of) the output of the LaTeX export: >>> >>> ,---- >>> | \section{Test} >>> | \label{sec-1} >>> | >>> | This is a broken >>> | 10 >>> | >>> | paragraph. >>> `---- >> >> The attached patch solves the problem. It may be a bit intrusive, >> though. >> >> Eric, what do you think? >> > > Invariably someone would then ask why the newline is being stripped from > their inline code block. > > I think this is only necessary because the R code block is returning > "10\n" instead of 10. Ideally this should be fixed in ob-R.el. > Maybe the fix should ideally live in ob-R, but I do not agree that someone should expect "10\n" to be returned from an inline source block. For two reasons (I seem to remember to have read these on this list before...) 1. The person who gets '10' but wants '10\n' can easily fix this in the inline source code. The other way around I can not fix it. 2. At present, if the inline code returns '10\n' it does not stay inline. So, why is it an inline code at the first place? At least from the exported document's viewpoint then the inline code could as well be a regular code block. So, what is the use of an inline block then? My use-case is quite simple: I quite often want small inline code blocks in my writing. Something like 'the sample size was n = src_R[:results raw]{nrow(P)}' In the mean time I'll go with Nicolas' patch -- thanks a lot, Nicolas! Best, Andreas > Best, > >> >> >> Regards, >> >> -- >> Nicolas Goaziou >> >> From 8ec02a2fa79b8601565ca7b226b8c1e4790f3439 Mon Sep 17 00:00:00 2001 >> From: Nicolas Goaziou >> Date: Fri, 13 Dec 2013 21:40:33 +0100 >> Subject: [PATCH] ob-core: Preserve paragraph when evaluating inline blocks >> >> * lisp/ob-core.el (org-babel-insert-result): Trim whitespaces around >> results from inline source blocks. >> --- >> lisp/ob-core.el | 14 ++++++++------ >> 1 file changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/lisp/ob-core.el b/lisp/ob-core.el >> index 84caed7..a6945e4 100644 >> --- a/lisp/ob-core.el >> +++ b/lisp/ob-core.el >> @@ -2048,12 +2048,14 @@ code ---- the results are extracted in the syntax of the source >> (or (> visible-beg existing-result) >> (<= visible-end existing-result)))) >> beg end) >> - (when (and (stringp result) ; ensure results end in a newline >> - (not inlinep) >> - (> (length result) 0) >> - (not (or (string-equal (substring result -1) "\n") >> - (string-equal (substring result -1) "\r")))) >> - (setq result (concat result "\n"))) >> + ;; Ensure inline results never end with a newline, but regular >> + ;; results always do. >> + (cond ((not (stringp result))) >> + (inlinep (setq result (org-babel-trim result))) >> + ((and (> (length result) 0) >> + (not (or (string-equal (substring result -1) "\n") >> + (string-equal (substring result -1) "\r")))) >> + (setq result (concat result "\n")))) >> (unwind-protect >> (progn >> (when outside-scope-p (widen))