[PATCH] inline src block results can be removed

[PATCH] inline src block results can be removed

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 902 bytes --]


Inline src blocks cannot update their results --- causing some of us 
heaadaches [1].

These patches fix that by placing the result of an inline src block in an 
export snippet with a faux :back-end called 'babel'.

So C-c C-c with point on src_R{1+2} will insert `@@babel:3@@'. Updating 
the contents of the inline src block and retyping C-c C-c will update the 
snippet. On export, these snippets are rendered using the verbatim 
transcoder, e.g. \texttt{3} for latex backends.

Support for most backends is provided.

org-babel-execute-buffer will also update such snippets.

Please try these patches out.

Remember to recompile the files that these patches modify or you will get 
wrong results when you restart emacs.

HTH,

Chuck

Footnote: [1] http://thread.gmane.org/gmane.emacs.orgmode/92481

p.s. If these patchesa are (eventually) acceptable, FSF has a copyright 
assignment for me on file.

[-- Attachment #2: ob-exp.el patch --]
[-- Type: TEXT/PLAIN, Size: 1260 bytes --]

From 78a365d223a969f407efa524b0c45e701b4ae908 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Tue, 11 Nov 2014 12:53:01 -0800
Subject: [PATCH 1/5] lisp/ob-exp.el: Enable removable inline src results

* lisp/ob-exp.el (org-babel-exp-do-export): Clean `@@babel:result@@'
  after inline src block.
---
 lisp/ob-exp.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index edb889c..83359e5 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -315,7 +315,9 @@ The function respects the value of the :exports header argument."
   (let ((silently (lambda () (let ((session (cdr (assoc :session (nth 2 info)))))
 			       (when (not (and session (equal "none" session)))
 				 (org-babel-exp-results info type 'silent)))))
-	(clean (lambda () (unless (eq type 'inline) (org-babel-remove-result info)))))
+	(clean (lambda () (if (eq type 'inline)
+			      (org-babel-delete-babel-snippet info)
+			    (org-babel-remove-result info)))))
     (case (intern (or (cdr (assoc :exports (nth 2 info))) "code"))
       ('none (funcall silently) (funcall clean) "")
       ('code (funcall silently) (funcall clean) (org-babel-exp-code info type))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #3: export-snippet patch --]
[-- Type: TEXT/PLAIN, Size: 6534 bytes --]

From 5e84279ff5dbbcb3e9c8f89c88afc15441286aec Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Tue, 11 Nov 2014 13:01:22 -0800
Subject: [PATCH 2/5] Inline src blocks are export-snippets

   * lisp/ox-latex.el (org-latex-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.

   * lisp/ox-beamer.el (org-beamer-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.

   * lisp/ox-html.el (org-html-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.

   * lisp/ox-ascii.el (org-ascii-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.

   * lisp/ox-texinfo.el (org-texinfo-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.

   * lisp/ox-odt.el (org-odt-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.

   * lisp/ox-man.el (org-man-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.
---
 lisp/ox-ascii.el   | 8 ++++++--
 lisp/ox-beamer.el  | 2 ++
 lisp/ox-html.el    | 7 +++++--
 lisp/ox-latex.el   | 8 +++++---
 lisp/ox-man.el     | 8 ++++++--
 lisp/ox-odt.el     | 8 +++++---
 lisp/ox-texinfo.el | 7 +++++--
 7 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index daad00f..695277c 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -1213,8 +1213,12 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
 (defun org-ascii-export-snippet (export-snippet contents info)
   "Transcode a EXPORT-SNIPPET object from Org to ASCII.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (when (eq (org-export-snippet-backend export-snippet) 'ascii)
-    (org-element-property :value export-snippet)))
+  (let ((backend (org-export-snippet-backend export-snippet)))
+    (cond ((eq  backend 'ascii)
+	   (org-element-property :value export-snippet))
+	  ((eq backend 'babel)
+	   (org-ascii-verbatim export-snippet contents info)))))
+
 
 
 ;;;; Export Block
diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 15bbce2..9f71cbb 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -291,6 +291,8 @@ channel."
 	(value (org-element-property :value export-snippet)))
     ;; Only "latex" and "beamer" snippets are retained.
     (cond ((eq backend 'latex) value)
+	  ((eq backend 'babel)
+	   (org-latex-verbatim export-snippet contents info))
 	  ;; Ignore "beamer" snippets specifying overlays.
 	  ((and (eq backend 'beamer)
 		(or (org-export-get-previous-element export-snippet info)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 20d09eb..e377687 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2268,8 +2268,11 @@ information."
   "Transcode a EXPORT-SNIPPET object from Org to HTML.
 CONTENTS is nil.  INFO is a plist holding contextual
 information."
-  (when (eq (org-export-snippet-backend export-snippet) 'html)
-    (org-element-property :value export-snippet)))
+  (let ((backend (org-export-snippet-backend export-snippet)))
+    (cond ((eq  backend 'html)
+	   (org-element-property :value export-snippet))
+	  ((eq backend 'babel)
+	   (org-html-verbatim export-snippet contents info))))) 
 
 ;;;; Export Block
 
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 8b38f96..232de73 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1392,9 +1392,11 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
 (defun org-latex-export-snippet (export-snippet contents info)
   "Transcode a EXPORT-SNIPPET object from Org to LaTeX.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (when (eq (org-export-snippet-backend export-snippet) 'latex)
-    (org-element-property :value export-snippet)))
-
+  (let ((backend (org-export-snippet-backend export-snippet)))
+    (cond ((eq  backend 'latex)
+	   (org-element-property :value export-snippet))
+	  ((eq backend 'babel)
+	   (org-latex-verbatim export-snippet contents info))))) 
 
 ;;;; Fixed Width
 
diff --git a/lisp/ox-man.el b/lisp/ox-man.el
index 9bbc52d..76fa99d 100644
--- a/lisp/ox-man.el
+++ b/lisp/ox-man.el
@@ -446,8 +446,12 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
 (defun org-man-export-snippet (export-snippet contents info)
   "Transcode a EXPORT-SNIPPET object from Org to Man.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (when (eq (org-export-snippet-backend export-snippet) 'man)
-    (org-element-property :value export-snippet)))
+  (let ((backend (org-export-snippet-backend export-snippet)))
+    (cond ((eq  backend 'man)
+	   (org-element-property :value export-snippet))
+	  ((eq backend 'babel)
+	   (org-man-verbatim export-snippet contents info)))))
+
 
 
 ;;; Fixed Width
diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 3b2596f..19db439 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -1673,9 +1673,11 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
 (defun org-odt-export-snippet (export-snippet contents info)
   "Transcode a EXPORT-SNIPPET object from Org to ODT.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (when (eq (org-export-snippet-backend export-snippet) 'odt)
-    (org-element-property :value export-snippet)))
-
+  (let ((backend (org-export-snippet-backend export-snippet)))
+    (cond ((eq  backend 'odt)
+	   (org-element-property :value export-snippet))
+	  ((eq backend 'babel)
+	   (org-odt-verbatim export-snippet contents info)))))
 
 ;;;; Export Block
 
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index 20508a1..6004c65 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -708,8 +708,11 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
 (defun org-texinfo-export-snippet (export-snippet contents info)
   "Transcode a EXPORT-SNIPPET object from Org to Texinfo.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (when (eq (org-export-snippet-backend export-snippet) 'texinfo)
-    (org-element-property :value export-snippet)))
+  (let ((backend (org-export-snippet-backend export-snippet)))
+    (cond ((eq  backend 'texinfo)
+	   (org-element-property :value export-snippet))
+	  ((eq backend 'babel)
+	   (org-texinfo-verbatim export-snippet contents info))))) 
 
 ;;;; Fixed Width
 
-- 
1.9.3 (Apple Git-50)


[-- Attachment #4: ox-md.el export snippets --]
[-- Type: TEXT/PLAIN, Size: 1968 bytes --]

From 54a94ea382eab1138bacbb38c0064f6feedea50f Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Tue, 11 Nov 2014 13:05:00 -0800
Subject: [PATCH 3/5] Inline src blocks are export-snippets

* lisp/ox-md.el (org-md-export-snippet): For babel; snippet use
  verbatim, otherwise use the html transcoder.
---
 lisp/ox-md.el | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-md.el b/lisp/ox-md.el
index f3fdedc..27da308 100644
--- a/lisp/ox-md.el
+++ b/lisp/ox-md.el
@@ -72,6 +72,7 @@ This variable can be set to either `atx' or `setext'."
 		     (comment-block . (lambda (&rest args) ""))
 		     (example-block . org-md-example-block)
 		     (export-block . org-md-export-block)
+		     (export-snippet . org-md-export-snippet)
 		     (fixed-width . org-md-example-block)
 		     (footnote-definition . ignore)
 		     (footnote-reference . ignore)
@@ -156,7 +157,7 @@ channel."
 	    value)))
 
 
-;;;; Example Block, Src Block and export Block
+;;;; Example Block, Src Block, export Block, export snippet
 
 (defun org-md-example-block (example-block contents info)
   "Transcode EXAMPLE-BLOCK element into Markdown format.
@@ -175,7 +176,17 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
     ;; Also include HTML export blocks.
     (org-export-with-backend 'html export-block contents info)))
 
-
+(defun org-md-export-snippet (export-snippet contents info)
+  "Transcode a EXPORT-SNIPPET object from Org to HTML.
+CONTENTS is nil.  INFO is a plist holding contextual
+information."
+  (let ((backend (org-export-snippet-backend export-snippet)))
+    (cond ((eq  backend 'html)
+	   (org-export-with-backend 'html export-snippet contents
+	   info))
+	  ((eq backend 'babel)
+	   (org-md-verbatim export-snippet contents info))))) 
+  
 ;;;; Headline
 
 (defun org-md-headline (headline contents info)
-- 
1.9.3 (Apple Git-50)


[-- Attachment #5: ox-man.el export snippet --]
[-- Type: TEXT/PLAIN, Size: 934 bytes --]

From 576ecdbbafcc95fcf1760fd4274b155512e09b60 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Tue, 11 Nov 2014 13:49:18 -0800
Subject: [PATCH 4/5] Inline src blocks are export-snippets

* lisp/ox-man.org (org-man-export-snippet): Treat the babel
   `:back-end' export-snippet value as verbatim.
---
 lisp/ox-man.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-man.el b/lisp/ox-man.el
index 76fa99d..4cd6cdf 100644
--- a/lisp/ox-man.el
+++ b/lisp/ox-man.el
@@ -450,7 +450,10 @@ CONTENTS is nil.  INFO is a plist holding contextual information."
     (cond ((eq  backend 'man)
 	   (org-element-property :value export-snippet))
 	  ((eq backend 'babel)
-	   (org-man-verbatim export-snippet contents info)))))
+	   (org-man-verbatim
+	    export-snippet
+	    (org-element-property :value export-snippet)
+	    info)))))
 
 
 
-- 
1.9.3 (Apple Git-50)


[-- Attachment #6: ob-core.el export snippet patch --]
[-- Type: TEXT/PLAIN, Size: 3103 bytes --]

From fdf7e79ed152c652c5666ce9e5ab3f1270bf72c5 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Tue, 11 Nov 2014 15:32:41 -0800
Subject: [PATCH 5/5] lisp/ob-core.el: Enable removable inline src results

* lisp/ob-core.al (org-babel-inline-result-wrap,
  org-babel-insert-result, org-babel-delete-babel-snippet): Inline src
  blocks results are export-snippets with a faux `:back-end' of `babel'.

  (org-babel-inline-result-wrap): Now `@@babel:%s@@'.
  (org-babel-delete-babel-snippet): Remove a babel export-snippet.
  (org-babel-insert-result): Remove a babel export snippet.

  The treatment of inline src block results as verbatim,
  e.g. `=result=', makes finding and removing them programatically
  tricky and risky.  By wrapping them as `@@babel:result@@' they can
  be found and removed.
---
 lisp/ob-core.el | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 6c38677..471ff25 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -156,7 +156,7 @@ See also `org-babel-noweb-wrap-start'."
   :group 'org-babel
   :type 'string)
 
-(defcustom org-babel-inline-result-wrap "=%s="
+(defcustom org-babel-inline-result-wrap "@@babel:%s@@"
   "Format string used to wrap inline results.
 This string must include a \"%s\" which will be replaced by the results."
   :group 'org-babel
@@ -2136,8 +2136,9 @@ code ---- the results are extracted in the syntax of the source
 		  (goto-char (match-end 0))
 		  (insert (if (listp result) "\n" " "))
 		  (point))))
-	     (existing-result (unless inlinep
-				(org-babel-where-is-src-block-result
+	     (existing-result (if inlinep
+				(org-babel-delete-babel-snippet)
+                                (org-babel-where-is-src-block-result
 				 t info hash indent)))
 	     (results-switches
 	      (cdr (assoc :results_switches (nth 2 info))))
@@ -2279,6 +2280,22 @@ code ---- the results are extracted in the syntax of the source
 	   (if keep-keyword (1+ (match-end 0)) (1- (match-beginning 0)))
 	   (progn (forward-line 1) (org-babel-result-end))))))))
 
+(defun org-babel-delete-babel-snippet (&optional info)
+  "When point is before a babel export-snippet, delete it."
+  (let ((location  (org-babel-where-is-src-block-result nil info)))
+    (when location 
+      (save-excursion
+	(goto-char location)
+	(when
+	    (looking-at "\\([[:space:]]*\\)\\([@]\\)")
+          (goto-char (match-end 1))
+          (let ((export-snippet (org-element-export-snippet-parser)))
+            (if export-snippet
+                (let ((start (org-element-property :begin export-snippet))
+                      (end (org-element-property :end export-snippet)))
+                  (and (eq (org-export-snippet-backend export-snippet) 'babel)
+                       (delete-region start end))))))))))
+
 (defun org-babel-remove-result-one-or-many (x)
   "Remove the result of the current source block.
 If called with a prefix argument, remove all result blocks
-- 
1.9.3 (Apple Git-50)

Re: [PATCH] inline src block results can be removed

[Andreas Leha]

Hi Chuck,

"Charles C. Berry" <ccberry@ucsd.edu> writes:
> Inline src blocks cannot update their results --- causing some of us
> heaadaches [1].
>
> These patches fix that by placing the result of an inline src block in
> an export snippet with a faux :back-end called 'babel'.
>
> So C-c C-c with point on src_R{1+2} will insert
> `@@babel:3@@'. Updating the contents of the inline src block and
> retyping C-c C-c will update the snippet. On export, these snippets
> are rendered using the verbatim transcoder, e.g. \texttt{3} for latex
> backends.
>
> Support for most backends is provided.
>
> org-babel-execute-buffer will also update such snippets.
>
> Please try these patches out.
>
> Remember to recompile the files that these patches modify or you will
> get wrong results when you restart emacs.
>
> HTH,
>
> Chuck
>
> Footnote: [1] http://thread.gmane.org/gmane.emacs.orgmode/92481
>
> p.s. If these patchesa are (eventually) acceptable, FSF has a
> copyright assignment for me on file.

First of all: Thanks a lot!  I'll (try to find time to) test these
patches.

Reading your description, I already have a first further feature
request, though ;-)  Or rather a question.

It sounds as if your patches turn inline source into limited source
blocks in terms of adherence to header arguments.  Given that most
likely there are not too many header arguments on inline source blocks,
this might not be a huge problem.

But my first question would be about ':results raw', as I never had a
case where I wanted the results of my inline source block to be
\texttt{}.

I guess, my question is: Do your patches restrict the use of babel
headers on inline source blocks.  And if so, is that just a matter of
'not implemented yet' or is there a fundamental issue here?

Thanks,
Andreas

Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

On Wed, 12 Nov 2014, Andreas Leha wrote:

> Hi Chuck,
>
> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>> Inline src blocks cannot update their results --- causing some of us
>> heaadaches [1].
>>
[deleted announcement of fix]

>
> First of all: Thanks a lot!  I'll (try to find time to) test these
> patches.
>

Yes. Please try them.

> Reading your description, I already have a first further feature
> request, though ;-)  Or rather a question.
>
> It sounds as if your patches turn inline source into limited source
> blocks in terms of adherence to header arguments.  Given that most
> likely there are not too many header arguments on inline source blocks,
> this might not be a huge problem.
>

See below ":results latex" and friends seem to work as before.

It would be nice if others could point out any hiccups.

> But my first question would be about ':results raw', as I never had a
> case where I wanted the results of my inline source block to be
> \texttt{}.

If you start with src_R{1+2} and evaluate it, you get the `@@babel:3@@'.

If you modify that to src_R[:results raw]{1+2} and evaluate it, the 
`@@...@@' goes away and is replaced with the raw result `3'. Of course, 
you are then stuck with that and cannot easily make further revisions.

However, with modest tooling, you can set up the :results header 
bufferwide so that when you want to export, the '@@...@@' will be removed 
from the temp buffer and the export will use `raw' results for inline src 
blocks.

Or you can make a custom version of org-latex-export-snippet that uses a 
different transcoder. Or you can just return the raw text and the 
`@@babel:3@@' will end up in the *.tex as 3. Just change the last line to 
(org-element-property :value export-snippet)[more parens] to get the raw 
value all the time.

>
> I guess, my question is: Do your patches restrict the use of babel
> headers on inline source blocks.  And if so, is that just a matter of
> 'not implemented yet' or is there a fundamental issue here?
>

I do not think things are worse with the patches.

src_R[:results latex]{1+2} is the same with the patches, I think. But 
ideally, that would generate something that acts like @@latex:3@@ and that 
could be safely removed.

In terms of implementation, if one wanted fine control over each inline 
src block, more tooling will be needed. Export snippets do not have lots 
of stops and whistles to play with, just a :back-end and a :value and 
location info. One could use `org-export-get-previous-element' to look up 
the header args and figure out what to do next. But that can get hairy if 
the header arg needs further processing. Considering the limited use to 
which inline src blocks are put, it probably is not coding up loads of 
tricky features.

Best,

Chuck

Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Chuck,

2014ko azaroak 12an, "Charles C. Berry"-ek idatzi zuen:
> 
> Inline src blocks cannot update their results --- causing some of us 
> heaadaches [1].
> 
> These patches fix that by placing the result of an inline src block in an 
> export snippet with a faux :back-end called 'babel'.
> 
> So C-c C-c with point on src_R{1+2} will insert `@@babel:3@@'. Updating 
> the contents of the inline src block and retyping C-c C-c will update the 
> snippet. On export, these snippets are rendered using the verbatim 
> transcoder, e.g. \texttt{3} for latex backends.
> 
> Support for most backends is provided.
> 
> org-babel-execute-buffer will also update such snippets.

Instead of using an export snippet, which requires per-backend changes,
you could wrap results in a macro, e.g. {{{results(2)}}}.

Users could customize this macro per-buffer (with the usual #+macro
keyword) to provide their own formatting of inline results.  You
could provide the fallback interpretation in the second call to
‘org-macro-replace-all’ in ‘org-export-as’ (currently responsible
for expanding a few macros like {{{author}}} and {{{date}}}).

What do you think of this idea?

-- 
Aaron Ecay

Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2147 bytes --]

On Wed, 12 Nov 2014, Aaron Ecay wrote:

> Hi Chuck,
>
> 2014ko azaroak 12an, "Charles C. Berry"-ek idatzi zuen:
>>
>> Inline src blocks cannot update their results --- causing some of us
>> heaadaches [1].
>>
>> These patches fix that by placing the result of an inline src block in an
>> export snippet with a faux :back-end called 'babel'.
>>
>> So C-c C-c with point on src_R{1+2} will insert `@@babel:3@@'. Updating
>> the contents of the inline src block and retyping C-c C-c will update the
>> snippet. On export, these snippets are rendered using the verbatim
>> transcoder, e.g. \texttt{3} for latex backends.
>>
>> Support for most backends is provided.
>>
>> org-babel-execute-buffer will also update such snippets.
>
> Instead of using an export snippet, which requires per-backend changes,
> you could wrap results in a macro, e.g. {{{results(2)}}}.
>
> Users could customize this macro per-buffer (with the usual #+macro
> keyword) to provide their own formatting of inline results.  You
> could provide the fallback interpretation in the second call to
> ‘org-macro-replace-all’ in ‘org-export-as’ (currently responsible
> for expanding a few macros like {{{author}}} and {{{date}}}).
>
> What do you think of this idea?
>

Aaron,

I like the flexibility that macros would allow.

Some care needs to be taken with commas, but not a big deal.

I don't think the usual #+MACRO works here, as the definition would be 
found in `org-macro-templates' by the first call and existing stuff would 
be expanded instead of being left for babel to remove it. But setting it 
up as a document keyword should work, right?

Don't know if there are other gotchas.

Maybe a limited collection of formats could be set up to support basic 
markup options and the macro could choose amongst them with a second arg 
set by a babel header arg.

I am not quite sure how to marry this to header args. Maybe the :wrap 
header arg should be hijacked for inline src blocks to specify a macro for 
the results.

I mean, does anyone actually use stuff like src_R[:wrap latex]{1+2}? The 
current result cannot be parsed as an export block, AFAICS.

Chuck

Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

Hello,

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> I like the flexibility that macros would allow.

I like it too. Macros are much better than export snippets for the task.

> I don't think the usual #+MACRO works here, as the definition would be
> found in `org-macro-templates' by the first call and existing stuff
> would be expanded instead of being left for babel to remove it. But
> setting it up as a document keyword should work, right?
>
> Don't know if there are other gotchas.
>
> Maybe a limited collection of formats could be set up to support basic
> markup options and the macro could choose amongst them with a second
> arg set by a babel header arg.

I think {{{results()}}} should remain a dumb wrapper itself and not try
to do some formatting (i.e., a simple, hard-coded macro). Formatting
should be on the side of Babel and, possibly, its arguments. Let's not
duplicate features.

> I am not quite sure how to marry this to header args. Maybe the :wrap
> header arg should be hijacked for inline src blocks to specify a macro
> for the results.

Macro can be the default output. If you don't want a macro, use raw
header. IOW, there is no need for a specific header arg.

> I mean, does anyone actually use stuff like src_R[:wrap latex]{1+2}?
> The current result cannot be parsed as an export block, AFAICS.

It could evaluate to @@latex:3@@. Parsing can also be solved if
necessary.

Thanks for your work.


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] inline src block results can be removed

[Andreas Leha]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> I like the flexibility that macros would allow.
>
> I like it too. Macros are much better than export snippets for the task.
>
>> I don't think the usual #+MACRO works here, as the definition would be
>> found in `org-macro-templates' by the first call and existing stuff
>> would be expanded instead of being left for babel to remove it. But
>> setting it up as a document keyword should work, right?
>>
>> Don't know if there are other gotchas.
>>
>> Maybe a limited collection of formats could be set up to support basic
>> markup options and the macro could choose amongst them with a second
>> arg set by a babel header arg.
>
> I think {{{results()}}} should remain a dumb wrapper itself and not try
> to do some formatting (i.e., a simple, hard-coded macro). Formatting
> should be on the side of Babel and, possibly, its arguments. Let's not
> duplicate features.
>
>> I am not quite sure how to marry this to header args. Maybe the :wrap
>> header arg should be hijacked for inline src blocks to specify a macro
>> for the results.
>
> Macro can be the default output. If you don't want a macro, use raw
> header. IOW, there is no need for a specific header arg.
>
>> I mean, does anyone actually use stuff like src_R[:wrap latex]{1+2}?
>> The current result cannot be parsed as an export block, AFAICS.
>
> It could evaluate to @@latex:3@@. Parsing can also be solved if
> necessary.
>

Without too much value to add to this thread at this point, I just want
to say, that I love the direction this thread has taken.  There is
good reason now to hope for better inline results handling in org.

> Thanks for your work.

I second that!  Thanks, Chuck!

Regards,
Andreas

Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2218 bytes --]


Nicolas,

More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el are 
patched.

A few examples of how they render various src_<lang>[headers]{code} setups 
are also attached.

Discussion inline below.


On Thu, 13 Nov 2014, Nicolas Goaziou wrote:

> Hello,
>
> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> I like the flexibility that macros would allow.
>
> I like it too. Macros are much better than export snippets for the task.
>
>> I don't think the usual #+MACRO works here, as the definition would be
>> found in `org-macro-templates' by the first call and existing stuff
>> would be expanded instead of being left for babel to remove it. But
>> setting it up as a document keyword should work, right?
>>
>> Don't know if there are other gotchas.
>>
>> Maybe a limited collection of formats could be set up to support basic
>> markup options and the macro could choose amongst them with a second
>> arg set by a babel header arg.
>
> I think {{{results()}}} should remain a dumb wrapper itself and not try
> to do some formatting (i.e., a simple, hard-coded macro). Formatting
> should be on the side of Babel and, possibly, its arguments. Let's not
> duplicate features.
>

Point taken.

Also, the user can customize org-babel-inline-result-wrap to always get 
verbatim or otherwise wrap the contents of the macro.

>> I am not quite sure how to marry this to header args. Maybe the :wrap
>> header arg should be hijacked for inline src blocks to specify a macro
>> for the results.
>
> Macro can be the default output. If you don't want a macro, use raw
> header. IOW, there is no need for a specific header arg.
>
>> I mean, does anyone actually use stuff like src_R[:wrap latex]{1+2}?
>> The current result cannot be parsed as an export block, AFAICS.
>
> It could evaluate to @@latex:3@@. Parsing can also be solved if
> necessary.

  `:wrap latex' results in @@latex: ... @@.

  `:results latex' results in
:     @@LaTeX:
:     <results>@@

which is a bit unsightly, but can be parsed and removed.

I have not touched
  - :RESULTS drawers
  - lists
  - tables

---

I appreciate your coaching/feedback.

Aaron Ecay's suggestion to use a macro was a good one. Thanks Aron.

Best,

Chuck

[-- Attachment #2: ob-core.el patch --]
[-- Type: TEXT/PLAIN, Size: 4976 bytes --]

From b369b0a1e69fd2b91c8f4eb7d824dcd18232917b Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:45:01 -0800
Subject: [PATCH 1/3] lisp/ob-core.el: Replace inline `results' macro call or
 export-snippet

* lisp/ob-core.el (org-babel-inline-result-wrap): Default is "{{{results(%s)}}}".

* lisp/ob-core.el (org-babel-insert-result): Delete any `results'
  macro or export-snippet immediately following inline src block;
  insert current value in 'results' macro or export snippet if :wrap
  header argument is given. Escape commas in the result with
  backslashes if the macro form is used.

* lisp/ob-core.el (org-babel-delete-babel-snippet): Add function to
  delete "{{{results(.*)}}}" macro calls or "@@backend:.*@@" provided
  they follow inline src blocks.  Adding extra spaces between an
  export snippet and its inline src block will protect it from
  removal.
---
 lisp/ob-core.el | 49 +++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 6c38677..227c8f0 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -156,7 +156,7 @@ See also `org-babel-noweb-wrap-start'."
   :group 'org-babel
   :type 'string)
 
-(defcustom org-babel-inline-result-wrap "=%s="
+(defcustom org-babel-inline-result-wrap "{{{results(%s)}}}"
   "Format string used to wrap inline results.
 This string must include a \"%s\" which will be replaced by the results."
   :group 'org-babel
@@ -2136,8 +2136,9 @@ code ---- the results are extracted in the syntax of the source
 		  (goto-char (match-end 0))
 		  (insert (if (listp result) "\n" " "))
 		  (point))))
-	     (existing-result (unless inlinep
-				(org-babel-where-is-src-block-result
+	     (existing-result (if inlinep
+				(org-babel-delete-babel-snippet)
+                                (org-babel-where-is-src-block-result
 				 t info hash indent)))
 	     (results-switches
 	      (cdr (assoc :results_switches (nth 2 info))))
@@ -2216,6 +2217,12 @@ code ---- the results are extracted in the syntax of the source
 		 ((member "file" result-params)
 		  (when inlinep (goto-char inlinep))
 		  (insert result))
+		 ;; escape commas, e.g. {{{results(a\,b)}}} 
+		 ((and inlinep
+		       (equal  '("replace") result-params)
+		       (not (assoc :wrap (nth 2 info))))
+		  (goto-char beg)
+		  (insert  (replace-regexp-in-string "," "\\," result nil t)))
 		 (t (goto-char beg) (insert result)))
 		(when (funcall proper-list-p result) (goto-char (org-table-end)))
 		(setq end (point-marker))
@@ -2223,12 +2230,18 @@ code ---- the results are extracted in the syntax of the source
 		(cond
 		 ((assoc :wrap (nth 2 info))
 		  (let ((name (or (cdr (assoc :wrap (nth 2 info))) "RESULTS")))
-		    (funcall wrap (concat "#+BEGIN_" name)
-			     (concat "#+END_" (car (org-split-string name))))))
+		    (if inlinep
+			(funcall wrap (concat "@@" name ":") "@@" nil t)
+		      (funcall wrap (concat "#+BEGIN_" name)
+			       (concat "#+END_" (car (org-split-string name)))))))
 		 ((member "html" result-params)
-		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML"))
-		 ((member "latex" result-params)
-		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX"))
+		  (if inlinep
+		      (funcall wrap "@@HTML:" "@@")
+		    (funcall wrap "#+BEGIN_HTML" "#+END_HTML")))
+		 ((member "latex" result-params) 
+		  (if inlinep
+		      (funcall wrap "@@LaTeX:" "@@")
+		    (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX")))
 		 ((member "org" result-params)
 		  (goto-char beg) (if (org-at-table-p) (org-cycle))
 		  (if inlinep
@@ -2279,6 +2292,26 @@ code ---- the results are extracted in the syntax of the source
 	   (if keep-keyword (1+ (match-end 0)) (1- (match-beginning 0)))
 	   (progn (forward-line 1) (org-babel-result-end))))))))
 
+(defun org-babel-delete-babel-snippet (&optional info)
+  "When point is in an inline src block, delete an export-snippet
+or `results' macro call just after it. To protect export snippets
+from removal, add extra spaces between the src block and the
+snippet."
+  (let ((location  (org-babel-where-is-src-block-result nil info)))
+    (when location 
+      (save-excursion
+	(goto-char location)
+	(cond
+	    ((looking-at "\\([ ]\\{1,2\\}\\)\\(@\\)")
+	     (goto-char (match-end 1))
+	     (let ((export-snippet (org-element-export-snippet-parser)))
+	       (if export-snippet
+		   (let ((start (org-element-property :begin export-snippet))
+			 (end (org-element-property :end export-snippet)))
+		     (delete-region start end)))))
+	    ((looking-at "\\([[:space:]]*\\)\\({{{results(.*?)}}}\\)")
+	     (delete-region (match-end 1) (match-end 2))))))))
+
 (defun org-babel-remove-result-one-or-many (x)
   "Remove the result of the current source block.
 If called with a prefix argument, remove all result blocks
-- 
1.9.3 (Apple Git-50)


[-- Attachment #3: ob-exp.el patch --]
[-- Type: TEXT/PLAIN, Size: 1292 bytes --]

From c69e49f551d4dbef0753512ac7dd89115478244b Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:49:57 -0800
Subject: [PATCH 2/3] lisp/ob-exp.el: Enable removable inline src results

* lisp/ob-exp.el (org-babel-exp-do-export): After inline src block clean
`@@<backend>:<result>@@' or `{{{results(<result>}}}'.
---
 lisp/ob-exp.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index edb889c..83359e5 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -315,7 +315,9 @@ The function respects the value of the :exports header argument."
   (let ((silently (lambda () (let ((session (cdr (assoc :session (nth 2 info)))))
 			       (when (not (and session (equal "none" session)))
 				 (org-babel-exp-results info type 'silent)))))
-	(clean (lambda () (unless (eq type 'inline) (org-babel-remove-result info)))))
+	(clean (lambda () (if (eq type 'inline)
+			      (org-babel-delete-babel-snippet info)
+			    (org-babel-remove-result info)))))
     (case (intern (or (cdr (assoc :exports (nth 2 info))) "code"))
       ('none (funcall silently) (funcall clean) "")
       ('code (funcall silently) (funcall clean) (org-babel-exp-code info type))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #4: ox.el patch --]
[-- Type: TEXT/PLAIN, Size: 969 bytes --]

From d510c83e5eb027ca2e8678b5557ac3af870a588b Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:55:36 -0800
Subject: [PATCH 3/3] lisp/ox.el: Enable removable inline src results

* lisp/ox.el: (org-export-as): Treat `results' as an `identity' macro
  with one argument after Babel executes.
---
 lisp/ox.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index d04e97a..fd7c67a 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2885,7 +2885,8 @@ Return code as a string."
 		;; EMAIL is not a parsed keyword: store it as-is.
 		(cons "email" (or (plist-get info :email) ""))
 		(cons "title"
-		      (org-element-interpret-data (plist-get info :title))))
+		      (org-element-interpret-data (plist-get info :title)))
+		(cons "results" "$1"))
 	  'finalize)
 	 ;; Parse buffer.
 	 (setq tree (org-element-parse-buffer nil visible-only))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #5: examples of inline src calls and output --]
[-- Type: TEXT/PLAIN, Size: 780 bytes --]


Executing these commands:

src_emacs-lisp[:wrap latex]{"Aa,b"} @@latex: wrap    @@ 
src_emacs-lisp[:results raw]{"a,b"} @@latex: raw     @@ 
src_emacs-lisp{"A,B,C"} @@latex: macro    @@             
src_emacs-lisp[:results latex]{"a,b"} @@latex: :results latex   @@ 
src_emacs-lisp[:wrap latex]{"a,b"}    @@latex: KEEP ME!!!   @@ 
src_emacs-lisp{"a,b"}                   {{{results(DEELETE ME)}}}   

Gives this output:

src_emacs-lisp[:wrap latex]{"Aa,b"} @@latex:Aa,b@@ 
src_emacs-lisp[:results raw]{"a,b"} a,b 
src_emacs-lisp{"A,B,C"} {{{results(A\,B\,C)}}} 
src_emacs-lisp[:results latex]{"a,b"} @@LaTeX:
a,b@@
 
src_emacs-lisp[:wrap latex]{"a,b"} @@latex:a,b@@    @@latex: KEEP ME!!!   @@ 
src_emacs-lisp{"a,b"} {{{results(a\,b)}}}                      

Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
> are patched.

Thanks.

> Also, the user can customize org-babel-inline-result-wrap to always
> get verbatim or otherwise wrap the contents of the macro.

I don't think this is a good idea.

If we rely on the macro recognition to properly inline results, setting
to anything else would break Org. It should be a defconst or we are
bound to shoot ourselves in the foot.

If a user wants verbatim output, he will have to somehow generate
{{{results:=output=}}}, e.g., through appropriate code or parameters.

>
>  `:wrap latex' results in @@latex: ... @@.

I was thinking to {{{results(@@latex:...@@)}}}. A bit more verbose, but
you can also replace :wrap latex results.

>  `:results latex' results in
> :     @@LaTeX:
> :     <results>@@
>
> which is a bit unsightly, but can be parsed and removed.

It is important to remove the spurious newline character, as it could
break the surrounding structure.

> I have not touched
>  - :RESULTS drawers
>  - lists
>  - tables

These have to be ignored. An inline element cannot generate a non-inline
element. At least, we shouldn't make it easy to do that. There are
plenty other ways to generate those.

> From b369b0a1e69fd2b91c8f4eb7d824dcd18232917b Mon Sep 17 00:00:00 2001
> From: chasberry <ccberry@ucsd.edu>
> Date: Thu, 13 Nov 2014 20:45:01 -0800
> Subject: [PATCH 1/3] lisp/ob-core.el: Replace inline `results' macro call or
>  export-snippet
>
> * lisp/ob-core.el (org-babel-inline-result-wrap): Default is
> "{{{results(%s)}}}".

As written earlier, I highly suggest to make it a defconst.

> * lisp/ob-core.el (org-babel-insert-result): Delete any `results'
>   macro or export-snippet immediately following inline src block;
>   insert current value in 'results' macro or export snippet if :wrap
>   header argument is given. Escape commas in the result with
>   backslashes if the macro form is used.

You also need to escape backslash characters before commas, per 

  (info "(org) Macro replacement")

> * lisp/ob-core.el (org-babel-delete-babel-snippet): Add function to
>   delete "{{{results(.*)}}}" macro calls or "@@backend:.*@@" provided
>   they follow inline src blocks.  Adding extra spaces between an
>   export snippet and its inline src block will protect it from
>   removal.

With {{{results(@@backend:...@@)}}}, we don't need the extra trick. Even
if it is more verbose, I think a regular syntax is better.

> +		 ;; escape commas, e.g. {{{results(a\,b)}}} 

Missing capital and final dot.

> +		 ((and inlinep
> +		       (equal  '("replace") result-params)

Spurious space.

> +		       (not (assoc :wrap (nth 2 info))))

`assq'

>  		(cond
>  		 ((assoc :wrap (nth 2 info))
>  		  (let ((name (or (cdr (assoc :wrap (nth 2 info))) "RESULTS")))
> -		    (funcall wrap (concat "#+BEGIN_" name)
> -			     (concat "#+END_" (car (org-split-string name))))))
> +		    (if inlinep
> +			(funcall wrap (concat "@@" name ":") "@@" nil t)
> +		      (funcall wrap (concat "#+BEGIN_" name)
> +			       (concat "#+END_" (car (org-split-string name)))))))
>  		 ((member "html" result-params)
> -		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML"))
> -		 ((member "latex" result-params)
> -		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX"))
> +		  (if inlinep
> +		      (funcall wrap "@@HTML:" "@@")
> +		    (funcall wrap "#+BEGIN_HTML" "#+END_HTML")))
> +		 ((member "latex" result-params) 
> +		  (if inlinep
> +		      (funcall wrap "@@LaTeX:" "@@")

I'd rather have back-end names lowercase @@html:...@@ and @@latex:...@@
even though they are case insensitive anyway.

Also, you can avoid repeating "funcall wrap":

  (apply wrap (if inlinep '("@@latex:" "@@") '("#+begin_latex" "#+end_latex")))

> +(defun org-babel-delete-babel-snippet (&optional info)
> +  "When point is in an inline src block, delete an export-snippet
> +or `results' macro call just after it. To protect export snippets
> +from removal, add extra spaces between the src block and the
> +snippet."
> +  (let ((location  (org-babel-where-is-src-block-result nil info)))
> +    (when location 
> +      (save-excursion
> +	(goto-char location)
> +	(cond
> +	    ((looking-at "\\([ ]\\{1,2\\}\\)\\(@\\)")
> +	     (goto-char (match-end 1))
> +	     (let ((export-snippet (org-element-export-snippet-parser)))

Don't call dedicated parser functions directly. The public functions are
`org-element-at-point' and `org-element-context'.

Anyway, this is not useful if we don't write directly export snippets.

> +	       (if export-snippet
> +		   (let ((start (org-element-property :begin export-snippet))
> +			 (end (org-element-property :end export-snippet)))
> +		     (delete-region start end)))))
> +	    ((looking-at "\\([[:space:]]*\\)\\({{{results(.*?)}}}\\)")
> +	     (delete-region (match-end 1) (match-end 2))))))))

Using `org-element-context' may be better.

WDYT?


Regards,

Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Chuck, Hi Nicolas,

I had a response to Chuck’s earlier message that was sitting around
waiting to be finished...time marches on however.  Apologies.  I think
the following bit is the only part that’s potentially still relevant:

> 
> I don't think the usual #+MACRO works here, as the definition would be 
> found in `org-macro-templates' by the first call and existing stuff would 
> be expanded instead of being left for babel to remove it. 

I see what you mean.  One option might be to do the following in
org-export-as (untested pseudocode):

(org-macro-initialize-templates)
(let (results-macro)
  (setq results-macro (assoc "results" org-macro-templates))
  (setq org-macro-templates (remove results-macro org-macro-templates))
  (org-macro-replace-all org-macro-templates)
  (org-export-execute-babel-code)
  (org-macro-replace-all (list (or results-macro
                                   (cons "results"
                                         org-default-result-macro) ;; new defcustom or defvar
                                   ))))

Back to the present:

2014ko azaroak 14an, Nicolas Goaziou-ek idatzi zuen:
> 
> "Charles C. Berry" <ccberry@ucsd.edu> writes:
> 
>> More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
>> are patched.
> 
> Thanks.
> 
>> Also, the user can customize org-babel-inline-result-wrap to always
>> get verbatim or otherwise wrap the contents of the macro.
> 
> I don't think this is a good idea.
> 
> If we rely on the macro recognition to properly inline results, setting
> to anything else would break Org. It should be a defconst or we are
> bound to shoot ourselves in the foot.
> 
> If a user wants verbatim output, he will have to somehow generate
> {{{results:=output=}}}, e.g., through appropriate code or parameters.

This is a step back from the present situation, where a user can get
a custom format applied by default to all inline results by setting
‘org-babel-inline-result-wrap’.  I think it’s reasonable for users to
want to set off babel results in a special font (to indicate that
they are automatically generated, e.g.)  This proposal would add an
additional overhead for generating this formatting to every inline
call.

I think the method I sketched above will allow users to redefine the
results macro in the same way as any other macro (via #+MACRO), thus
allowing the possibility of user-specified special formatting.

[...]

>> * lisp/ob-core.el (org-babel-inline-result-wrap): Default is
>> "{{{results(%s)}}}".
> 
> As written earlier, I highly suggest to make it a defconst.

Indeed, this seems correct.  (The “const” designation is just a hint to
users/developers – it doesn’t affect the ability of people who really
want to customize the value to setq it to something else in their init
file.)

> With {{{results(@@backend:...@@)}}}, we don't need the extra trick. Even
> if it is more verbose, I think a regular syntax is better.

This doesn’t mesh with the suggestion to allow the results macro to
supply formatting.

-- 
Aaron Ecay

Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

On Fri, 14 Nov 2014, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
>> are patched.
>
> Thanks.
>

[skipping to the bottom - omitting useful critiques of code and
  opinions about strategy and tactics from Nicolas]

> WDYT?

After staring at `org-babel-insert-result' for too long, I am beginning to 
feel like Alice in Wonderland. As currently implemented, inline src blocks 
are somewhere between fragile and broken.  I worry about making them even 
more fragile, the logic in `org-babel-insert-result' has plenty of twists 
ans turns, and I cannot commit the effort to dig deeply into them. So I am 
looking for an easy way out.

For now, I'd be willing to make patches that will allow removal of the
inline src block results that do *not* involve these header args:

- :file <fn>
- :wrap <wrapper>
- :results latex html drawer org code

which I can do barely touching `org-babel-insert-result' and this
simplifies matters a lot.

I propose to do this by using the patches of ox.el and ob-exp.el from
my last post. For ob-core.el, I would

- leave defcustom org-babel-inline-wrap as "=%s=" (or use defconst - I
   do not have a strong opinion either way).
- allow replacement of exising results in `org-babel-insert-result'
   like so
   #+BEGIN_EXAMPLE
     -     (existing-result (unless inlinep
     -(org-babel-where-is-src-block-result
     +     (existing-result (if inlinep
     +(org-babel-delete-results-macro)
     +    (org-babel-where-is-src-block-result
   #+END_EXAMPLE
   and defun `org-babel-delete-results-macro' per Nicolas' suggestions
   for `org-babel-delete-babel-snippet' (from earlier patch) to use
   `org-element-context' and friends (and not mess with export
   snippets).
- modify `org-babel-examplify-region' along these lines
   #+BEGIN_SRC emacs-lisp
     (insert
      (replace-regexp-in-string
       "," "\\,"
       (format
        (concat "{{{results("
                org-babel-inline-result-wrap
                ")}}}"
                (prog1 (buffer-substring beg end)
                  (delete-region beg end))))
       nil t))

   #+END_SRC


I believe that this is simple enough to avoid breaking idioms that
folks might use now.

As for the choice between "=%s=" and "%s", the latter was hard coded
until f285b7ed3d097dd1cbb55fa3c31bc92aa0149054 in February 2013 and
has been the default since. It also parallels what happens with
handling src block results. Going forward I do not think this
behavior should change.

I have too litle experience with #+MACROs to know if Aaron's
suggestion to let the user customize the macro is opening up potential
issues when users get `creative'.

I can do what I've outlined in the coming days.

If it is felt that more retooling of `org-babel-insert-results' is really 
needed, I can get to it early next year. In fact, I'll be out of email 
range from late this month till then, so any problems I create now will 
have to wait till then for me to work on them.

Thanks for the critique of my earlier patches and your thoughts.

Best,

Chuck

Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> This is a step back from the present situation, where a user can get
> a custom format applied by default to all inline results by setting
> ‘org-babel-inline-result-wrap’.  I think it’s reasonable for users to
> want to set off babel results in a special font (to indicate that
> they are automatically generated, e.g.)  This proposal would add an
> additional overhead for generating this formatting to every inline
> call.

I expect Babel to provide a parameter to generate verbatim output, and
a way to use this parameter globally. If it doesn't, then we can keep
`org-babel-inline-result-wrap' and simply wrap {{{results(...)}}} macro
around the output.

> I think the method I sketched above will allow users to redefine the
> results macro in the same way as any other macro (via #+MACRO), thus
> allowing the possibility of user-specified special formatting.

Babel output is expected to be modified by Babel functions/variables.
I wouldn't want to see macro used as the main tool to modify inline
Babel output.

Of course, you can still do it. But you're on your own.
{{{results(...)}}} is just a wrapper.

> Indeed, this seems correct.  (The “const” designation is just a hint to
> users/developers – it doesn’t affect the ability of people who really
> want to customize the value to setq it to something else in their init
> file.)

Of course, users are free to break their local copy of Org.

>> With {{{results(@@backend:...@@)}}}, we don't need the extra trick. Even
>> if it is more verbose, I think a regular syntax is better.
>
> This doesn’t mesh with the suggestion to allow the results macro to
> supply formatting.

See above.


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> For now, I'd be willing to make patches that will allow removal of the
> inline src block results that do *not* involve these header args:
>
> - :file <fn>
> - :wrap <wrapper>
> - :results latex html drawer org code
>
> which I can do barely touching `org-babel-insert-result' and this
> simplifies matters a lot.

IMO, we're too much focused on the implementation details. We ought to
agree on what should be done first. For example, considering
`org-babel-insert-result' and its RESULT-PARAMS argument, I think the
following makes sense:

  | Param   | Example output                    |
  |---------+-----------------------------------|
  | default | {{{results(42)}}}                 |
  | file    | {{{results(file:something.pdf)}}} |
  | list    |                                   |
  | raw     | 42                                |
  | drawer  |                                   |
  | org     | {{{results(src_org{...})}}}        |
  | html    | {{{results(@@html:...@@)}}}       |
  | latex   | {{{results(@@latex:...@@)}}}      |
  | code    | {{{results(src_xxx{...})}}}        |

Basically, it should be possible to remove any kind of result using
"results" macro, with the exception of "raw".  "list" and "drawer" can
be ignored since there is no inline equivalent.

Another option for "drawer" is to also use export snippets. So,
basically, "drawer something" would generate
{{{results(@@something:...@@)}}}.

> I propose to do this by using the patches of ox.el and ob-exp.el from
> my last post. For ob-core.el, I would
>
> - leave defcustom org-babel-inline-wrap as "=%s=" (or use defconst - I
>    do not have a strong opinion either way).

`org-babel-inline-wrap' as a defcustom is fine if you hardcode
{{{results(...)}}} wrapping at a higher level.

> - modify `org-babel-examplify-region' along these lines
>    #+BEGIN_SRC emacs-lisp
>      (insert
>       (replace-regexp-in-string
>        "," "\\,"
>        (format
>         (concat "{{{results("
>                 org-babel-inline-result-wrap
>                 ")}}}"
>                 (prog1 (buffer-substring beg end)
>                   (delete-region beg end))))
>        nil t))
>
>    #+END_SRC

But this is unrelated to "examplify". Wrapping should probably be
a dedicated function systematically called on results from an inline
block.

> If it is felt that more retooling of `org-babel-insert-results' is really 
> needed, I can get to it early next year. In fact, I'll be out of email 
> range from late this month till then, so any problems I create now will 
> have to wait till then for me to work on them.

It's going to be difficult not to alter `org-babel-insert-results' since
the plan is to change completely how inline source blocks are handled.

There's no rush, however. Non-removable results from inline source
blocks have been there for a long time.


Regards,

Re: [PATCH] inline src block results can be removed

[Daniele Pizzolli]

On 2014-11-17 00:23, Nicolas Goaziou wrote:
> "Charles C. Berry" writes:
> 
>> For now, I'd be willing to make patches that will allow removal of the
>> inline src block results that do *not* involve these header args:

[]

> IMO, we're too much focused on the implementation details. We ought to
> agree on what should be done first. For example, considering
> `org-babel-insert-result' and its RESULT-PARAMS argument, I think the
> following makes sense:
> 
>   | Param   | Example output                    |
>   |---------+-----------------------------------|
>   | default | {{{results(42)}}}                 |
>   | file    | {{{results(file:something.pdf)}}} |
>   | list    |                                   |
>   | raw     | 42                                |
>   | drawer  |                                   |
>   | org     | {{{results(src_org{...})}}}       |
>   | html    | {{{results(@@html:...@@)}}}       |
>   | latex   | {{{results(@@latex:...@@)}}}      |
>   | code    | {{{results(src_xxx{...})}}}       |
> 
> Basically, it should be possible to remove any kind of result using
> "results" macro, with the exception of "raw".  "list" and "drawer" can
> be ignored since there is no inline equivalent.

[]

> There's no rush, however. Non-removable results from inline source
> blocks have been there for a long time.

Hello all,

I jump into this conversation because in the next months I will try to
write a supplementary information annex using org-mode with Gnu R, so
my idea on what should be done follows...

I guess I will start my project using those patches.  Thanks!

A brief review on how how results are presented (or usually
anticipated) inline led me to the following wish list:

* provide some facilities to keep track of the 'unit of measurement'

Few numbers are pure numbers.  There is a little value added to the
correctness of the work as a whole if I get the correct number from
babel but I have hard coded the wrong unit of measure in the text.

Please follow the examples.

# Load used languages
#+BEGIN_SRC emacs-lisp
(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . nil)
(octave . t)
(R . t)))
#+END_SRC

Ideally, I think that reasonable solution would take table like the
following:

#+TBLNAME:speed-1
| speed | speed_unit |
|-------+------------|
|    12 | km/s       |

and output by default or through an easy to call syntax:

#+BEGIN_EXAMPLE
12 km/s
#+END_EXAMPLE

I am not aware of any facilities provided by languages like R or
octave to keep track of the unit of measure, If you have some please
share.

A more space wise representation, that add another layer of
indirection would be to have a look-up table like the following:

#+TBLNAME:speed-1-units-lookup
| name   | unit |
|--------+------|
| speed  | km/s |
| length | km   |
| time   | s    |

But I am not sure that it's worth it, at least for those that are
working with small data sets.

* support for inline rendering of tables

The most complex inline output I think I will need at some point
follows:

#+TBLNAME:data-set-1
#+NAME:data-set-1
| position | item1 | author1 | item2 | author2 | correlation |
|----------+-------+---------+-------+---------+-------------|
|        1 | i1    | a1      | j1    | b1      | c1          |
|        2 | i2    | a2      | j2    | b2      | c2          |
|        3 | i3    | a3      | j3    | b3      | c3          |

#+NAME: block-1
#+BEGIN_SRC R :session :colnames yes :exports none :var 
data_set_1=data-set-1
# Just to show that we use R
data_set_2 <- data_set_1
#+END_SRC

#+RESULTS: block-1
| position | item1 | author1 | item2 | author2 | correlation |
|----------+-------+---------+-------+---------+-------------|
|        1 | i1    | a1      | j1    | b1      | c1          |
|        2 | i2    | a2      | j2    | b2      | c2          |
|        3 | i3    | a3      | j3    | b3      | c3          |


And I really like to be easily rendered as an inline string through
some formatting specs e.g.:

#+BEGIN_EXAMPLE
#+PROPERTY: header-args: R :fmt '(%(position)i) “%(item1)s” by 
/%(author1)s/ correlate to “%(item2)s” by /%(author2)s/  with a 
correlation coefficient of %(correlation).2f'
#+PROPERTY: header-args: R :rowsep (', ', ' and ')

The preliminary results show that: src_R[:session :results 
replace]{data_set_2}.
#+END_EXAMPLE

Will be rendered as:

#+BEGIN_org
The preliminary results show that:
(1) “i1” by /a1/ correlate to “j1” by /b1/ with a correlation 
coefficient of c1,
(2) “i2” by /a2/ correlate to “j2” by /b2/ with a correlation 
coefficient of c2 and
(3) “i3” by /a3/ correlate to “j3” by /b3/ with a correlation 
coefficient of c3.
#+END_org

For languages that does not support tables with headers we can stick
with the positional formatting:

#+NAME: block-2
#+BEGIN_SRC octave :session :colnames yes :exports none :var 
data_set_1=data-set-1
ans = data_set_1;
#+END_SRC

# TODO: figure out why this does not work
#+RESULTS: block-2
: iii123aaa123jjj123bbb123ccc123

#+BEGIN_EXAMPLE
#+PROPERTY: header-args: octave :fmt '(%i) “%s” by /%s/ correlate to 
“%s” by /%s/  with a correlation coefficient of %.2f'
#+PROPERTY: header-args: octave :rowsep (', ', ' and ')
The preliminary results show that: src_octave[:session :results 
replace)]{ans}.
#+END_EXAMPLE

#+BEGIN_org
The preliminary results show that:
(1) “i1” by /a1/ correlate to “j1” by /b1/ with a correlation 
coefficient of c1,
(2) “i2” by /a2/ correlate to “j2” by /b2/ with a correlation 
coefficient of c2 and
(3) “i3” by /a3/ correlate to “j3” by /b3/ with a correlation 
coefficient of c3.
#+END_org

* support for humanization

A minor point would be supporting some humanization of the numbers
using extended format placeholder to support:

- number-as-word or number-as-cardinal :: 1 -> one
- number-as-ordinal :: 2 -> second
- number-as-pretty-fraction :: 2.3333 -> 2 + 1/3
- number-as-word-fraction :: 2.3333 -> two and one third
- number-as-natural-size :: 1000000 -> 1.0 MB
- number-as-natural-size-binary :: 1000000 -> 976.6 KiB

* auto formatting standard test result

It would be nice to simplify the insertion of the result of standard
test like Chi-square by taking the =R= result and rewrite in a
sentence form:

#+BEGIN_org
\Chi-squared = 0.214, d.f. = 1, p-value < 0.05
#+END_org

But this is really lower priority because it will need a lot work to
keep track of language and test specific parameters.

* Conclusion

I really like to hear your feedback on those points.  Maybe am I
taking the avoidance of cute and paste point of the reproducible
research too far?

Best,
Daniele

Re: [PATCH] inline src block results can be removed

[Andreas Leha]

Hi Daniele,

I think your wishlist is somewhere further down the road.  I usually
implement some of your points in the src_language.  I see that it would
be nice if org supported these use cases, but I would see them as part
of the LOB or maybe in some package in contrib rather than in core
org/babel.

For that, I'd argue removable inline results that can be exported
without special formatting would be all that is needed to support your
wishlist.


A few inline comments below.


Daniele Pizzolli <dan@toel.it> writes:
> On 2014-11-17 00:23, Nicolas Goaziou wrote:
>> "Charles C. Berry" writes:
>> 
>>> For now, I'd be willing to make patches that will allow removal of the
>>> inline src block results that do *not* involve these header args:
>
> []
>
>> IMO, we're too much focused on the implementation details. We ought to
>> agree on what should be done first. For example, considering
>> `org-babel-insert-result' and its RESULT-PARAMS argument, I think the
>> following makes sense:
>> 
>>   | Param   | Example output                    |
>>   |---------+-----------------------------------|
>>   | default | {{{results(42)}}}                 |
>>   | file    | {{{results(file:something.pdf)}}} |
>>   | list    |                                   |
>>   | raw     | 42                                |
>>   | drawer  |                                   |
>>   | org     | {{{results(src_org{...})}}}       |
>>   | html    | {{{results(@@html:...@@)}}}       |
>>   | latex   | {{{results(@@latex:...@@)}}}      |
>>   | code    | {{{results(src_xxx{...})}}}       |
>> 
>> Basically, it should be possible to remove any kind of result using
>> "results" macro, with the exception of "raw".  "list" and "drawer" can
>> be ignored since there is no inline equivalent.
>
> []
>
>> There's no rush, however. Non-removable results from inline source
>> blocks have been there for a long time.
>
> Hello all,
>
> I jump into this conversation because in the next months I will try to
> write a supplementary information annex using org-mode with Gnu R, so
> my idea on what should be done follows...
>
> I guess I will start my project using those patches.  Thanks!
>
> A brief review on how how results are presented (or usually
> anticipated) inline led me to the following wish list:
>
> * provide some facilities to keep track of the 'unit of measurement'
>
> Few numbers are pure numbers.  There is a little value added to the
> correctness of the work as a whole if I get the correct number from
> babel but I have hard coded the wrong unit of measure in the text.
>
> Please follow the examples.
>
> # Load used languages
>
> #+BEGIN_SRC emacs-lisp
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((emacs-lisp . nil)
> (octave . t)
> (R . t)))
> #+END_SRC
>
>
> Ideally, I think that reasonable solution would take table like the
> following:
>
> #+TBLNAME:speed-1
> | speed | speed_unit |
> |-------+------------|
> |    12 | km/s       |
>
> and output by default or through an easy to call syntax:
>
> #+BEGIN_EXAMPLE
> 12 km/s
> #+END_EXAMPLE
>
>
> I am not aware of any facilities provided by languages like R or
> octave to keep track of the unit of measure, If you have some please
> share.
>
> A more space wise representation, that add another layer of
> indirection would be to have a look-up table like the following:
>
> #+TBLNAME:speed-1-units-lookup
> | name   | unit |
> |--------+------|
> | speed  | km/s |
> | length | km   |
> | time   | s    |
>

I usually have an even more elaborate legend table like

| name | display | unit |
|------+---------+------|
| sp   | speed   | km/s |
| le   | length  | km   |
| ti   | time    | s    |

And sometimes even (some) translation support:

| name | display | de              | unit |
|------+---------+-----------------+------|
| sp   | speed   | Geschwindigkeit | km/s |
| le   | length  | Länge           | km   |
| ti   | time    | Zeit            | s    |

Only the table is in org, the handling is done not by org, but in R.


> But I am not sure that it's worth it, at least for those that are
> working with small data sets.
>
> * support for inline rendering of tables
>
> The most complex inline output I think I will need at some point
> follows:
>
> #+TBLNAME:data-set-1
> #+NAME:data-set-1
> | position | item1 | author1 | item2 | author2 | correlation |
> |----------+-------+---------+-------+---------+-------------|
> |        1 | i1    | a1      | j1    | b1      | c1          |
> |        2 | i2    | a2      | j2    | b2      | c2          |
> |        3 | i3    | a3      | j3    | b3      | c3          |
>
> #+NAME: block-1
> #+BEGIN_SRC R :session :colnames yes :exports none :var 
>
> data_set_1=data-set-1
> # Just to show that we use R
> data_set_2 <- data_set_1
> #+END_SRC
>
> #+RESULTS: block-1
> | position | item1 | author1 | item2 | author2 | correlation |
>
> |----------+-------+---------+-------+---------+-------------|
> |        1 | i1    | a1      | j1    | b1      | c1          |
> |        2 | i2    | a2      | j2    | b2      | c2          |
> |        3 | i3    | a3      | j3    | b3      | c3          |
>
>
> And I really like to be easily rendered as an inline string through
> some formatting specs e.g.:
>
> #+BEGIN_EXAMPLE
> #+PROPERTY: header-args: R :fmt '(%(position)i) %(item1)s by 
> /%(author1)s/ correlate to %(item2)s by /%(author2)s/  with a 
> correlation coefficient of %(correlation).2f'
> #+PROPERTY: header-args: R :rowsep (', ', ' and ')
>
> The preliminary results show that: src_R[:session :results 
> replace]{data_set_2}.
> #+END_EXAMPLE
>
>
> Will be rendered as:
>
> #+BEGIN_org
> The preliminary results show that:
> (1) i1 by /a1/ correlate to j1 by /b1/ with a correlation 
> coefficient of c1,
> (2) i2 by /a2/ correlate to j2 by /b2/ with a correlation 
> coefficient of c2 and
> (3) i3 by /a3/ correlate to j3 by /b3/ with a correlation 
> coefficient of c3.
> #+END_org
>

I am not sure how that would create a general use case.  I think the
language needed to glue the table elements is highly content dependent.
I'd do that per use case and via the language, i.e. in R, instead.


>
> For languages that does not support tables with headers we can stick
> with the positional formatting:
>
> #+NAME: block-2
> #+BEGIN_SRC octave :session :colnames yes :exports none :var 
>
> data_set_1=data-set-1
> ans = data_set_1;
> #+END_SRC
>
> # TODO: figure out why this does not work
>
> #+RESULTS: block-2
> : iii123aaa123jjj123bbb123ccc123
>
> #+BEGIN_EXAMPLE
> #+PROPERTY: header-args: octave :fmt '(%i) %s by /%s/ correlate to 
> %s by /%s/  with a correlation coefficient of %.2f'
> #+PROPERTY: header-args: octave :rowsep (', ', ' and ')
> The preliminary results show that: src_octave[:session :results 
> replace)]{ans}.
> #+END_EXAMPLE
>
> #+BEGIN_org
> The preliminary results show that:
> (1) i1 by /a1/ correlate to j1 by /b1/ with a correlation 
> coefficient of c1,
> (2) i2 by /a2/ correlate to j2 by /b2/ with a correlation 
> coefficient of c2 and
> (3) i3 by /a3/ correlate to j3 by /b3/ with a correlation 
> coefficient of c3.
> #+END_org
>
>
> * support for humanization
>
> A minor point would be supporting some humanization of the numbers
> using extended format placeholder to support:
>
> - number-as-word or number-as-cardinal :: 1 -> one
> - number-as-ordinal :: 2 -> second
> - number-as-pretty-fraction :: 2.3333 -> 2 + 1/3
> - number-as-word-fraction :: 2.3333 -> two and one third
> - number-as-natural-size :: 1000000 -> 1.0 MB
> - number-as-natural-size-binary :: 1000000 -> 976.6 KiB

There is some support for that in R (e.g. digits2text in
http://rattle.togaware.com/utility.R) as well, which should be easy to
wrap into an org block to call from your LOB.

>
> * auto formatting standard test result
>
> It would be nice to simplify the insertion of the result of standard
> test like Chi-square by taking the =R= result and rewrite in a
> sentence form:
>
> #+BEGIN_org
> \Chi-squared = 0.214, d.f. = 1, p-value < 0.05
> #+END_org
>
> But this is really lower priority because it will need a lot work to
> keep track of language and test specific parameters.

Are you aware of the 'ascii' R package?  That package focuses on
creating tables for various backend (including org) of a number of
scenarios.  I'd see such functionality again more on R's side.  Maybe as
a new package R2org?

>
> * Conclusion
>

HTH,
Andreas

Re: [PATCH] inline src block results can be removed

[Daniele Pizzolli]

On 2014-11-24 11:18, Andreas Leha wrote:
> Hi Daniele,
> 
> I think your wishlist is somewhere further down the road.  I usually
> implement some of your points in the src_language.  I see that it would
> be nice if org supported these use cases, but I would see them as part
> of the LOB or maybe in some package in contrib rather than in core
> org/babel.
> 
> For that, I'd argue removable inline results that can be exported
> without special formatting would be all that is needed to support your
> wishlist.

Hi Andreas,

sure, I think I will start getting the string I needed from
src_language.  But in some language is really hard to get facilities
for text manipulation while the output as table generally supported.
And I also think that the fine grained control of the layout of the
inline sentence pertains to the org layer.

> A few inline comments below.

Thanks again, they are really a nice help to start with!

Best,
Daniele

Re: [PATCH] inline src block results can be removed

[Daniele Pizzolli]

On 2014-11-24 12:12, Daniele Pizzolli wrote:
> On 2014-11-24 11:18, Andreas Leha wrote:
>> Hi Daniele,
>> 
>> I think your wishlist is somewhere further down the road.  I usually
>> implement some of your points in the src_language.  I see that it 
>> would
>> be nice if org supported these use cases, but I would see them as part
>> of the LOB or maybe in some package in contrib rather than in core
>> org/babel.
>> 
>> For that, I'd argue removable inline results that can be exported
>> without special formatting would be all that is needed to support your
>> wishlist.
> 
> Hi Andreas,
> 
> sure, I think I will start getting the string I needed from
> src_language.  But in some language is really hard to get facilities
> for text manipulation while the output as table generally supported.
> And I also think that the fine grained control of the layout of the
> inline sentence pertains to the org layer.

Hi Andreas,

Yesterday I forgot to mention another reason because I think that the
formatting of the results pertains to the org layer and not to the
original language.

It's about proper boundaries and untrusted or limited trust of the
babel code.  By default I wish to run untrusted code and display in a
safely manner the result.  This is already possible by remote code
evaluation (but I not really checked if the output is always safely
escaped before the insertion in the org buffer).

Using the source language for outputting org-code is a viable
workaround for my needs but in the long run I will prefer to not
include some potential harmful generated org code.

I double checked about the output escaping right now.  I guessed that
the output in the raw mode was safely escaped.  But it really seems
the opposite: [[info:org#Results]].  However it seems that the RESULTS
code are not subsequently evaluated even with:

#+BEGIN_SRC elisp
(org-babel-do-load-languages
  'org-babel-load-languages
  '((sh . t)))

(setq org-export-babel-evaluate t)
#+END_SRC

Example:

#+NAME: is-this-safe-or-not
#+BEGIN_SRC sh :result output raw
printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && 
echo true; echo false}'
#+END_SRC

# TODO: the pipe causes a bug...
#+RESULTS: is-this-safe-or-not
: Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo 
true; echo false}

So now I am more confused than before...  Has anybody a proof or a
counterexample that is (im)possible to run safely untrusted code on
(untrusted) remote host and still have the local buffer trusted?

By the way I really wanted to write:

#+NAME: problem-with-pipes...
#+BEGIN_SRC sh :result output raw
printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && 
echo true || echo false}'
#+END_SRC

#+RESULTS: problem-with-pipes...
| Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo 
true |   | echo false} |

I guess that something is wrong here:
Org-mode version 8.3beta (release_8.3beta-485-gf70439 @ 
/home/user/.emacs.d/el-get/org-mode/lisp/)

Maybe we need a new result format for safe output or am I missing
something?

Thanks in advance,
Daniele

Re: [PATCH] inline src block results can be removed

[Andreas Leha]

Hi Daniele,

Daniele Pizzolli <dan@toel.it> writes:
> On 2014-11-24 12:12, Daniele Pizzolli wrote:
>> On 2014-11-24 11:18, Andreas Leha wrote:
>>> Hi Daniele,
>>> 
>>> I think your wishlist is somewhere further down the road.  I usually
>>> implement some of your points in the src_language.  I see that it 
>>> would
>>> be nice if org supported these use cases, but I would see them as part
>>> of the LOB or maybe in some package in contrib rather than in core
>>> org/babel.
>>> 
>>> For that, I'd argue removable inline results that can be exported
>>> without special formatting would be all that is needed to support your
>>> wishlist.
>> 
>> Hi Andreas,
>> 
>> sure, I think I will start getting the string I needed from
>> src_language.  But in some language is really hard to get facilities
>> for text manipulation while the output as table generally supported.
>> And I also think that the fine grained control of the layout of the
>> inline sentence pertains to the org layer.
>
> Hi Andreas,
>
> Yesterday I forgot to mention another reason because I think that the
> formatting of the results pertains to the org layer and not to the
> original language.
>
> It's about proper boundaries and untrusted or limited trust of the
> babel code.  By default I wish to run untrusted code and display in a
> safely manner the result.  This is already possible by remote code
> evaluation (but I not really checked if the output is always safely
> escaped before the insertion in the org buffer).

I agree in principle.  But there are limits.  Org cannot be expected to
know how to format any object I am creating to my liking.  So, in my
opinion there are 'standard objects' (like tables) that can be passed to
org and org can format them appropriately.  For more special and
targeted things I have to provide the formatting myself.

I also agree that it is much cleaner to separate the formatting from the
generation.  And whenever that is possible that's the way to go.  For
instance, I can pass my object as a table and have some custom code to do
the formatting.  That custom code does not have to be the same language
that generated the object, but can be any language with babel support.
I can then even make this very transparent by using the :post header
argument.
Simple (non-inline) example with a function to add hlines to tables (the
function is old and ugly, though...)

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

* Example
Add hlines to tables at arbitrary rows ignoring already existing hlines.

#+name: add-hlines
#+begin_src emacs-lisp :var x=(quote (("parameter" "value") ("amount" 1) ("margin" 12))) :var below=1
  (labels ((p-cumsum (boolean-list)
                     (if (not boolean-list)
                         0
                       (if (not (sequencep boolean-list))
                           1
                         (if (equal 1 (length boolean-list))
                             (list (if (car boolean-list) 1 0))
                           (let ((firstsum (p-cumsum (car boolean-list)))
                                 (lastsum (p-cumsum (cdr boolean-list))))
                             (cons firstsum
                                   (mapcar '(lambda (x) (+ firstsum x)) lastsum))))))))
    (let* ((h (mapcar (lambda(a) (not (equal a 'hline))) x))
           (hs (p-cumsum h))
           (below-list (if (listp below) below (list below)))
           (below-rows (reverse (sort below-list '<))))
      (message "%S" x)
      (message "%S" h)
      (message "%S" hs)
      (dolist (below-row below-rows)
        (let ((after-row (apply #'+ (mapcar '(lambda (x) (if (<= x below-row) 1 0)) hs))))
          (message "%S" after-row)
          (setq x
                (append (cl-subseq x 0 after-row)
                        (list 'hline)
                        (cl-subseq x after-row)))))
      x))
#+end_src



#+begin_src R :results table replace :post add-hlines[:results table](below='(2 3),x=*this*)
  data.frame(a=1:10, b=11:20)
#+end_src

#+results:
|  1 | 11 |
|  2 | 12 |
|----+----|
|  3 | 13 |
|----+----|
|  4 | 14 |
|  5 | 15 |
|  6 | 16 |
|  7 | 17 |
|  8 | 18 |
|  9 | 19 |
| 10 | 20 |
--8<---------------cut here---------------end--------------->8---





>
> Using the source language for outputting org-code is a viable
> workaround for my needs but in the long run I will prefer to not
> include some potential harmful generated org code.
>
> I double checked about the output escaping right now.  I guessed that
> the output in the raw mode was safely escaped.  But it really seems
> the opposite: [[info:org#Results]].  However it seems that the RESULTS
> code are not subsequently evaluated even with:

I do not think that style of 'recursive' evaluation is possible.  But
there is the :post header argument, see above.



>
> #+BEGIN_SRC elisp
> (org-babel-do-load-languages
>   'org-babel-load-languages
>   '((sh . t)))
>
> (setq org-export-babel-evaluate t)
> #+END_SRC
>
>
> Example:
>
> #+NAME: is-this-safe-or-not
> #+BEGIN_SRC sh :result output raw
>
> printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && 
> echo true; echo false}'
> #+END_SRC
>
> # TODO: the pipe causes a bug...
>
> #+RESULTS: is-this-safe-or-not
> : Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo 
>
> true; echo false}
>
> So now I am more confused than before...  Has anybody a proof or a
> counterexample that is (im)possible to run safely untrusted code on
> (untrusted) remote host and still have the local buffer trusted?
>
> By the way I really wanted to write:
>
> #+NAME: problem-with-pipes...
> #+BEGIN_SRC sh :result output raw
>
> printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && 
> echo true || echo false}'
> #+END_SRC
>
> #+RESULTS: problem-with-pipes...
> | Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo 
>
> true |   | echo false} |
>
> I guess that something is wrong here:
> Org-mode version 8.3beta (release_8.3beta-485-gf70439 @ 
> /home/user/.emacs.d/el-get/org-mode/lisp/)
>
> Maybe we need a new result format for safe output or am I missing
> something?
>
> Thanks in advance,
> Daniele

Best,
Andreas

New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3488 bytes --]

On Sun, 16 Nov 2014, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> For now, I'd be willing to make patches that will allow removal of the
>> inline src block results that do *not* involve these header args:
>>
>> - :file <fn>
>> - :wrap <wrapper>
>> - :results latex html drawer org code
>>
>> which I can do barely touching `org-babel-insert-result' and this
>> simplifies matters a lot.
>
> IMO, we're too much focused on the implementation details. We ought to
> agree on what should be done first. For example, considering
> `org-babel-insert-result' and its RESULT-PARAMS argument, I think the
> following makes sense:
>
>  | Param   | Example output                    |
>  |---------+-----------------------------------|
>  | default | {{{results(42)}}}                 |
>  | file    | {{{results(file:something.pdf)}}} |
>  | list    |                                   |
>  | raw     | 42                                |
>  | drawer  |                                   |
>  | org     | {{{results(src_org{...})}}}        |
>  | html    | {{{results(@@html:...@@)}}}       |
>  | latex   | {{{results(@@latex:...@@)}}}      |
>  | code    | {{{results(src_xxx{...})}}}        |
>
> Basically, it should be possible to remove any kind of result using
> "results" macro, with the exception of "raw".  "list" and "drawer" can
> be ignored since there is no inline equivalent.
>
> Another option for "drawer" is to also use export snippets. So,
> basically, "drawer something" would generate
> {{{results(@@something:...@@)}}}.
>

I'm back online.

I've attached three patches and two files that show the behavior under the 
current master (12 Jan 2015, e0879b03d08bb4acc663084076370482f61e8698) and 
under the patched version.

With the patches, inline source block results can be removed by 
re-executing the source block if they are wrapped in a 
`{{{results(...)}}}' macro. The schema for the RESULT-PARAMS is as 
follows, but see the examples for caveats:

   | Param           | Example output                    |
   |-----------------+-----------------------------------+
   | default/replace | {{{results(=42=)}}}               |
   | list            | \n: - 42\n\n                      |
   | raw             | 42                                |
   | drawer/wrap     | {{{results(42)}}}                 |
   | org             | {{{results(src_org{...})}}}       |
   | html            | {{{results(@@html:...@@)}}}       |
   | latex           | {{{results(@@latex:...@@)}}}      |
   | code            | {{{results(src_emacs-lisp{...})}}}|
   | table           | \n| 42 |\n\n                      |
   |-----------------+-----------------------------------+

where the default is `src_emacs-lisp{42}' and subsequent rows give the 
`:results' arg.

`:file my.pdf' produces `{{{results([[file:/my.pdf]])}}}', although
link style fontification and open on click are lost as a consequence.

Also `:wrap whatknot' does the obvious.

In addition a few bugs have been squashed (as seen in the difference 
between the two example files).

The `results' macro is hard coded to wrap `value' except when list, table, 
or raw is specified as a RESULT-PARAM or when (listp value). And obviously, :file

Users can still customize org-babel-inline-result-wrap, but the macro will 
wrap the around whatever it yields.

HTH,

Chuck

p.s. The November dates on the patches are a result of using
`git rebase -i' to squash newer commits on top of older ones.

[-- Attachment #2: ob-core.el patch --]
[-- Type: TEXT/PLAIN, Size: 11666 bytes --]

From badc80465860ad63251ae68170cc09daa676b490 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:45:01 -0800
Subject: [PATCH 1/3] lisp/ob-core.el: Inline source block results are
 replaceable

* lisp/ob-core.el (org-babel-insert-result): Delete any `results'
  macro following current inline src block; insert current value in
  'results' macro possibly wrapping RESULT in an export snippet or
  inline source block first. Protect commas and backslash commas in the
  RESULT with backslashes if the macro form is used.

* lisp/ob-core.el (org-babel-remove-inline-result): Add function to
  delete "{{{results(.*)}}}" macro call of current inline src block.

Inline source block results can be removed by re-executing the source
block if they are wrapped in a `{{{results(...)}}}' macro. The schema
for the RESULT-PARAMS is:

  | Param   | Example output                    |
  |---------+-----------------------------------+
  | default | {{{results(42)}}}                 |
  | file    | {{{results(file:something.pdf)}}} |
  | list    | \n: - 42\n\n                      |
  | raw     | 42                                |
  | drawer  | {{{results(42)}}}                 |
  | org     | {{{results(src_org{...})}}}       |
  | html    | {{{results(@@html:...@@)}}}       |
  | latex   | {{{results(@@latex:...@@)}}}      |
  | code    | {{{results(src_xxx{...})}}}       |
  | table   | \n| 42 |\n\n                      |
  |---------+-----------------------------------+

where the default is `src_emacs{42}' and subsequent rows give the `:results' arg.

The `:wrap something' header arg gives an effect similar to `:results html' or
`:results latex'.

On export, the macro is stripped away before parsing leaving only its contents.

Combining RESULT-PARAMS that use the `results' macro can cause
havoc. Standard source blocks or the `raw' arg should generally be
used for complicated constructions of RESULT-PARAMS, lists, tables,
and/or multi-line RESULTs.
---
 lisp/ob-core.el | 114 +++++++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 84 insertions(+), 30 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 93fcb2a..80542ec 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2073,13 +2073,18 @@ If the path of the link is a file path it is expanded using
 (defun org-babel-insert-result
   (result &optional result-params info hash indent lang)
   "Insert RESULT into the current buffer.
-By default RESULT is inserted after the end of the
-current source block.  With optional argument RESULT-PARAMS
-controls insertion of results in the org-mode file.
+By default RESULT is inserted after the end of the current source
+block.  The RESULT of an inline source block usually will be
+wrapped inside a `results' macro and placed on the same line as
+the inline source block. The macro is stripped upon
+export. Multiline and non-scalar RESULTS from inline source
+blocks are fragile and should be avoided. With optional argument
+RESULT-PARAMS controls insertion of results in the org-mode file.
 RESULT-PARAMS can take the following values:
 
 replace - (default option) insert results after the source block
-          replacing any previously inserted results
+          or inline source block replacing any previously
+          inserted results
 
 silent -- no results are inserted into the Org-mode buffer but
           the results are echoed to the minibuffer and are
@@ -2096,8 +2101,9 @@ raw ----- results are added directly to the Org-mode file.  This
           formatted text.
 
 drawer -- results are added directly to the Org-mode file as with
-          \"raw\", but are wrapped in a RESULTS drawer, allowing
-          them to later be replaced or removed automatically.
+          \"raw\", but are wrapped in a RESULTS drawer or results
+          macro, allowing them to later be replaced or removed
+          automatically.
 
 org ----- results are added inside of a \"src_org{}\" or \"#+BEGIN_SRC
           org\" block depending on whether the current source block is
@@ -2105,13 +2111,15 @@ org ----- results are added inside of a \"src_org{}\" or \"#+BEGIN_SRC
           but Org syntax here will be discarded when exporting the
           file.
 
-html ---- results are added inside of a #+BEGIN_HTML block.  This
-          is a good option if you code block will output html
-          formatted text.
+html ---- results are added inside of a #+BEGIN_HTML block or
+          html export snippet depending on whether the current
+          source block is inline or not.  This is a good option
+          if you code block will output html formatted text.
 
-latex --- results are added inside of a #+BEGIN_LATEX block.
-          This is a good option if you code block will output
-          latex formatted text.
+latex --- results are added inside of a #+BEGIN_LATEX block or
+          latex export snippet depending on whether the current
+          source block is inline or not.  This is a good option
+          if you code block will output latex formatted text.
 
 code ---- the results are extracted in the syntax of the source
           code of the language being evaluated and are added
@@ -2138,9 +2146,12 @@ code ---- the results are extracted in the syntax of the source
 		(when (or (org-babel-get-inline-src-block-matches)
 			  (org-babel-get-lob-one-liner-matches))
 		  (goto-char (match-end 0))
-		  (insert (if (listp result) "\n" " "))
+		  (insert (if (or (listp result)
+				  (member "list" result-params))
+			      "\n" " "))
 		  (point))))
-	     (existing-result (unless inlinep
+	     (existing-result (if inlinep
+				  (org-babel-remove-inline-result)
 				(org-babel-where-is-src-block-result
 				 t info hash indent)))
 	     (results-switches
@@ -2179,7 +2190,12 @@ code ---- the results are extracted in the syntax of the source
 		 ((member "prepend" result-params)))) ; already there
 	      (setq results-switches
 		    (if results-switches (concat " " results-switches) ""))
-	      (let ((wrap (lambda (start finish &optional no-escape no-newlines)
+	      (let ((wrap (lambda (start finish &optional no-escape no-newlines
+					 inline-start inline-finish)
+			    (when inlinep
+			      (setq start inline-start)
+			      (setq finish inline-finish)
+			      (setq no-newlines t))
 			    (goto-char end)
 			    (insert (concat finish (unless no-newlines "\n")))
 			    (goto-char beg)
@@ -2196,6 +2212,7 @@ code ---- the results are extracted in the syntax of the source
 		 ((null result))
 		 ;; insert a list if preferred
 		 ((member "list" result-params)
+		  (goto-char beg)
 		  (insert
 		   (org-babel-trim
 		    (org-list-to-generic
@@ -2220,6 +2237,19 @@ code ---- the results are extracted in the syntax of the source
 		 ((member "file" result-params)
 		  (when inlinep (goto-char inlinep))
 		  (insert result))
+		 ;; escape commas, e.g. {{{results(a\,b)}}} 
+		 ((and inlinep
+		       (not (member "raw" result-params)))
+		  (goto-char beg)
+		  (insert
+		   ;; Escape commas and preceding backslash per
+		   ;;  (info "(org) Macro replacement").
+		   (replace-regexp-in-string
+		    "\\(\\\\*\\)\\(,\\)"
+		    (lambda (str)
+		      (let ((len (length (match-string 1 str))))
+			(concat (make-string (* 2 (/ len 2)) ?\\) "\\,")))
+		    result nil t)))
 		 (t (goto-char beg) (insert result)))
 		(when (funcall proper-list-p result) (goto-char (org-table-end)))
 		(setq end (point-marker))
@@ -2228,34 +2258,41 @@ code ---- the results are extracted in the syntax of the source
 		 ((assoc :wrap (nth 2 info))
 		  (let ((name (or (cdr (assoc :wrap (nth 2 info))) "RESULTS")))
 		    (funcall wrap (concat "#+BEGIN_" name)
-			     (concat "#+END_" (car (org-split-string name))))))
+			     (concat "#+END_" (car (org-split-string name)))
+			     nil nil (concat "{{{results(@@" name ":") "@@)}}}")))
 		 ((member "html" result-params)
-		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML"))
-		 ((member "latex" result-params)
-		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX"))
+		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML" nil nil
+			   "{{{results(@@html:" "@@)}}}"))
+		 ((member "latex" result-params) 
+		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX" nil nil
+			   "{{{results(@@latex:" "@@)}}}"))
 		 ((member "org" result-params)
 		  (goto-char beg) (if (org-at-table-p) (org-cycle))
-		  (if inlinep
-		      (funcall wrap "src_org{" "}" nil t)
-		      (funcall wrap "#+BEGIN_SRC org" "#+END_SRC")))
+		  (funcall wrap "#+BEGIN_SRC org" "#+END_SRC" nil nil
+			   "{{{results(src_org{" "})}}}"))
 		 ((member "code" result-params)
 		  (let ((lang (or lang "none")))
-		    (if inlinep
-			(funcall wrap (format "src_%s[%s]{" lang results-switches)
-				 "}" nil t)
-			(funcall wrap (format "#+BEGIN_SRC %s%s" lang results-switches)
-				 "#+END_SRC"))))
+		    (funcall wrap (format "#+BEGIN_SRC %s%s" lang results-switches)
+			     "#+END_SRC" nil nil
+			     (format "{{{results(src_%s[%s]{" lang results-switches)
+			     "})}}}")))
 		 ((member "raw" result-params)
 		  (goto-char beg) (if (org-at-table-p) (org-cycle)))
 		 ((or (member "drawer" result-params)
 		      ;; Stay backward compatible with <7.9.2
 		      (member "wrap" result-params))
 		  (goto-char beg) (if (org-at-table-p) (org-cycle))
-		  (funcall wrap ":RESULTS:" ":END:" 'no-escape))
+		  (funcall wrap ":RESULTS:" ":END:" 'no-escape nil
+			   "{{{results(" ")}}}"))
+		 ((and inlinep (member "file" result-params))
+		  (funcall wrap nil nil nil nil "{{{results(" ")}}}"))
 		 ((and (not (funcall proper-list-p result))
 		       (not (member "file" result-params)))
-		  (org-babel-examplify-region beg end results-switches)
-		  (setq end (point)))))
+		  (let ((org-babel-inline-result-wrap
+			 ;; Hard code {{{results(...)}}} on top of customization.
+			 (format "{{{results(%s)}}}" org-babel-inline-result-wrap)))
+		    (org-babel-examplify-region beg end results-switches)
+		    (setq end (point))))))
 	      ;; possibly indent the results to match the #+results line
 	      (when (and (not inlinep) (numberp indent) indent (> indent 0)
 			 ;; in this case `table-align' does the work for us
@@ -2283,6 +2320,23 @@ code ---- the results are extracted in the syntax of the source
 	   (if keep-keyword (1+ (match-end 0)) (1- (match-beginning 0)))
 	   (progn (forward-line 1) (org-babel-result-end))))))))
 
+(defun org-babel-remove-inline-result ()
+  "Remove the result of the current inline-src-block if it is
+  wrapped in a `results' macro and trim extraneous leading whitespace."
+  (let ((el (org-element-context)) post-blank)
+    (when (eq (org-element-type el) 'inline-src-block)
+      (save-excursion
+	(setq post-blank (org-element-property :post-blank el))
+        (goto-char (org-element-property :end el))
+        (setq el (org-element-context))
+        (when (and (eq (org-element-type el) 'macro)
+                   (equal (org-element-property :key el) "results"))
+          (delete-region ; And (only) extra leading whitespace.
+           (- (org-element-property :begin el)
+	      (- post-blank 1))
+           (- (org-element-property :end el)
+	      (org-element-property :post-blank el))))))))
+
 (defun org-babel-remove-result-one-or-many (x)
   "Remove the result of the current source block.
 If called with a prefix argument, remove all result blocks
-- 
1.9.3 (Apple Git-50)


[-- Attachment #3: ob-exp.el patch --]
[-- Type: TEXT/PLAIN, Size: 1321 bytes --]

From afebac8d09a011ba087d858a7dca56f95bc28e69 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:49:57 -0800
Subject: [PATCH 2/3] ob-exp.el: Enable removal of {{{results(...)}}}

* ob-exp.el (org-babel-do-export): `clean' lambda form removes inline
  results wrapped in `results{{{(' `)}}}' by calling
  `org-babel-remove-inline-result'.
---
 lisp/ob-exp.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index edb889c..afe6cd9 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -315,7 +315,9 @@ The function respects the value of the :exports header argument."
   (let ((silently (lambda () (let ((session (cdr (assoc :session (nth 2 info)))))
 			       (when (not (and session (equal "none" session)))
 				 (org-babel-exp-results info type 'silent)))))
-	(clean (lambda () (unless (eq type 'inline) (org-babel-remove-result info)))))
+	(clean (lambda () (if (eq type 'inline)
+			      (org-babel-remove-inline-result info)
+			    (org-babel-remove-result info)))))
     (case (intern (or (cdr (assoc :exports (nth 2 info))) "code"))
       ('none (funcall silently) (funcall clean) "")
       ('code (funcall silently) (funcall clean) (org-babel-exp-code info type))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #4: ox.el patch --]
[-- Type: TEXT/PLAIN, Size: 969 bytes --]

From 279ff7bc2011bc23e581577ddcc7b209cf7cd0bd Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:55:36 -0800
Subject: [PATCH 3/3] lisp/ox.el: Enable removable inline src results

* lisp/ox.el: (org-export-as): Treat `results' as an `identity' macro
  with one argument after Babel executes.
---
 lisp/ox.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 8880e10..3d5c7f2 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2884,7 +2884,8 @@ Return code as a string."
 		;; EMAIL is not a parsed keyword: store it as-is.
 		(cons "email" (or (plist-get info :email) ""))
 		(cons "title"
-		      (org-element-interpret-data (plist-get info :title))))
+		      (org-element-interpret-data (plist-get info :title)))
+		(cons "results" "$1"))
 	  'finalize)
 	 ;; Parse buffer.
 	 (setq tree (org-element-parse-buffer nil visible-only))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #5: master output --]
[-- Type: TEXT/PLAIN, Size: 6067 bytes --]

Demonstrate inline-src block-behavior and the {{{results( )}}} macro.

The `demo' src block sets up an inline-src-block, calls it, then
exports the result. The output is as follows:

- inline-src-block :: inline-src-block with headers and content.
- export backend :: Which backend was used to render the result.
- result :: What the ~*.org~ buffer looks looks like after babel
     executes the inline-src-block.
- exported as :: Show the exported version (starting on the next line). 

* :results replace (default) 

#+name: demo
#+BEGIN_SRC emacs-lisp :var str="replace" bkend="ascii" contents="42"
  (let ((cmd (format "src_emacs-lisp[:results %s]{%s}" str contents)))
    (concat "inline-src-block: " cmd "\nexport backend: " bkend 
            "\nresult: " (with-temp-buffer
                           (insert cmd)
                           (ignore-errors
                            (org-babel-execute-buffer))
                           (buffer-string))
            "\nexported as:\n"
            (ignore-errors
              (org-export-string-as cmd (intern bkend) t))))
#+END_SRC

#+RESULTS: demo
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} =42=
: exported as:
: `42'

#+CALL: demo("replace")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} =42=
: exported as:
: `42'

* :results html under html backend

#+CALL: demo("html","html")

#+RESULTS:
#+begin_example
inline-src-block: src_emacs-lisp[:results html]{42}
export backend: html
result: src_emacs-lisp[:results html]{42} #+BEGIN_HTML
42#+END_HTML

exported as:
<p>
#+BEGIN<sub>HTML</sub>
42#+END<sub>HTML</sub>
</p>
#+end_example

* :results html under latex backend

#+CALL: demo("html","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html]{42}
: export backend: latex
: result: src_emacs-lisp[:results html]{42} #+BEGIN_HTML
: 42#+END_HTML
: 
: exported as:
: \#+BEGIN\(_{\text{HTML}}\)
: 42\#+END\(_{\text{HTML}}\)


* :results latex under latex backend

#+CALL: demo("latex","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results latex]{42}
: export backend: latex
: result: src_emacs-lisp[:results latex]{42} #+BEGIN_LaTeX
: 42#+END_LaTeX
: 
: exported as:
: \#+BEGIN\(_{\text{\LaTeX{}}}\)
: 42\#+END\(_{\text{\LaTeX{}}}\)


* :results replace :wrap ascii 

#+CALL: demo("replace :wrap ascii","ascii")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace :wrap ascii]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace :wrap ascii]{42} #+BEGIN_ascii
: 42#+END_ascii
: 
: exported as:
: #+BEGIN_ascii 42#+END_ascii


* :results raw

#+CALL: demo("raw")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results raw]{42}
: export backend: ascii
: result: src_emacs-lisp[:results raw]{42} 42
: exported as:
: 42


* :results drawer

Same as default.

#+CALL: demo("drawer")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results drawer]{42}
: export backend: ascii
: result: src_emacs-lisp[:results drawer]{42} :RESULTS:
: 42:END:
: 
: exported as:
: :RESULTS: 42:END:


* :results org

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("org")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results org]{42}
: export backend: ascii
: result: src_emacs-lisp[:results org]{42} src_org{42}
: exported as:


* :results code

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("code")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{42}
: export backend: ascii
: result: src_emacs-lisp[:results code]{42} src_emacs-lisp[]{42}
: exported as:
: `42'


* :results list

Lists and tables should be avoided for inline-src-blocks, but for
completeness some are listed here.

#+CALL: demo("list")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results list]{42}
: export backend: ascii
: result: s- 42
: : rc_emacs-lisp[:results list]{42} 
: exported as:


* :results table

#+CALL: demo("table")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results table]{42}
: export backend: ascii
: result: src_emacs-lisp[:results table]{42}
: | 42 |
: 
: exported as:
:  42 


* :results replace, proper list as content

Proper lists become tables.

#+CALL: demo(contents="\'(42)")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{'(42) }
: export backend: ascii
: result: src_emacs-lisp[:results replace]{'(42) }
: | 42 |
: 
: exported as:
:  42 


* :results replace, proper list as content, latex backend

#+CALL: demo(bkend="latex",contents="\'((42)(43))")

#+RESULTS:
#+begin_example
inline-src-block: src_emacs-lisp[:results replace]{'((42) (43))}
export backend: latex
result: src_emacs-lisp[:results replace]{'((42) (43))}
| 42 |
| 43 |

exported as:
\begin{center}
\begin{tabular}{r}
42\\
43\\
\end{tabular}
\end{center}
#+end_example

* :results list, proper list as content, latex backend

#+CALL: demo(str="list",bkend="latex",contents="\'((42)(43))")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results list]{'((42) (43))}
: export backend: latex
: result: s- (42)
: - (43)
: rc_emacs-lisp[:results list]{'((42) (43))}
: 
: exported as:

* :results html list

Don't mix :results args like this!

#+CALL: demo("html list")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html list]{42}
: export backend: ascii
: result: s- 42
: #+END_HTML
: rc_emacs-lisp[:results#+BEGIN_HTML
:  html list]{42} 
: exported as:


* :results code, contents as elisp

#+CALL: demo("code",contents="(quote (+ 1 2))")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{(quote (+ 1 2) )}
: export backend: ascii
: result: src_emacs-lisp[:results code]{(quote (+ 1 2) )} src_emacs-lisp[]{(+ 1 2)
: }
: exported as:
: src_emacs-lisp[]{(+ 1 2) }


[-- Attachment #6: patched output --]
[-- Type: TEXT/PLAIN, Size: 5899 bytes --]

Demonstrate inline-src block-behavior and the {{{results( )}}} macro.

The `demo' src block sets up an inline-src-block, calls it, then
exports the result. The output is as follows:

- inline-src-block :: inline-src-block with headers and content.
- export backend :: Which backend was used to render the result.
- result :: What the ~*.org~ buffer looks looks like after babel
     executes the inline-src-block.
- exported as :: Show the exported version (starting on the next line). 

* :results replace (default) 

#+name: demo
#+BEGIN_SRC emacs-lisp :var str="replace" bkend="ascii" contents="42"
  (let ((cmd (format "src_emacs-lisp[:results %s]{%s}" str contents)))
    (concat "inline-src-block: " cmd "\nexport backend: " bkend 
            "\nresult: " (with-temp-buffer
                           (insert cmd)
                           (org-babel-execute-buffer)
                           (buffer-string))
            "\nexported as:\n"
            (org-export-string-as cmd (intern bkend) t)))
#+END_SRC

#+RESULTS: demo
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} {{{results(=42=)}}}
: exported as:
: `42'


#+CALL: demo("replace")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} {{{results(=42=)}}}
: exported as:
: `42'

* :results html under html backend

#+CALL: demo("html","html")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html]{42}
: export backend: html
: result: src_emacs-lisp[:results html]{42} {{{results(@@html:42@@)}}}
: exported as:
: <p>
: 42</p>

* :results html under latex backend

#+CALL: demo("html","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html]{42}
: export backend: latex
: result: src_emacs-lisp[:results html]{42} {{{results(@@html:42@@)}}}
: exported as:

* :results latex under latex backend

#+CALL: demo("latex","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results latex]{42}
: export backend: latex
: result: src_emacs-lisp[:results latex]{42} {{{results(@@latex:42@@)}}}
: exported as:
: 42

* :results replace :wrap ascii 

#+CALL: demo("replace :wrap ascii","ascii")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace :wrap ascii]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace :wrap ascii]{42} {{{results(@@ascii:42@@)}}}
: exported as:
: 42

* :results raw

#+CALL: demo("raw")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results raw]{42}
: export backend: ascii
: result: src_emacs-lisp[:results raw]{42} 42
: exported as:
: 42

* :results drawer

Same as default.

#+CALL: demo("drawer")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results drawer]{42}
: export backend: ascii
: result: src_emacs-lisp[:results drawer]{42} {{{results(42)}}}
: exported as:
: 42

* :results org

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("org")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results org]{42}
: export backend: ascii
: result: src_emacs-lisp[:results org]{42} {{{results(src_org{42})}}}
: exported as:
: `42'

* :results code

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("code")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{42}
: export backend: ascii
: result: src_emacs-lisp[:results code]{42} {{{results(src_emacs-lisp[]{42})}}}
: exported as:
: `42'

* :results list

Lists and tables should be avoided for inline-src-blocks, but for
completeness some are listed here.

#+CALL: demo("list")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results list]{42}
: export backend: ascii
: result: src_emacs-lisp[:results list]{42}
: : - 42
: 
: exported as:
: ,----
: | - 42
: `----

* :results table

#+CALL: demo("table")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results table]{42}
: export backend: ascii
: result: src_emacs-lisp[:results table]{42}
: | 42 |
: 
: exported as:
:  42 

* :results replace, proper list as content

Proper lists become tables.

#+CALL: demo(contents="\'(42)")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{'(42) }
: export backend: ascii
: result: src_emacs-lisp[:results replace]{'(42) }
: | 42 |
: 
: exported as:
:  42 

* :results replace, proper list as content, latex backend

#+CALL: demo(bkend="latex",contents="\'((42)(43))")

#+RESULTS:
#+begin_example
inline-src-block: src_emacs-lisp[:results replace]{'((42) (43))}
export backend: latex
result: src_emacs-lisp[:results replace]{'((42) (43))}
| 42 |
| 43 |

exported as:
\begin{center}
\begin{tabular}{r}
42\\
43\\
\end{tabular}
\end{center}
#+end_example

* :results list, proper list as content, latex backend

#+CALL: demo(str="list",bkend="latex",contents="\'((42)(43))")

#+RESULTS:
#+begin_example
inline-src-block: src_emacs-lisp[:results list]{'((42) (43))}
export backend: latex
result: src_emacs-lisp[:results list]{'((42) (43))}
- (42)
- (43)

exported as:
\begin{itemize}
\item (42)
\item (43)
\end{itemize}
#+end_example

* :results html list

Don't mix :results args like this!

#+CALL: demo("html list")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html list]{42}
: export backend: ascii
: result: src_emacs-lisp[:results html list]{42}
: {{{results(@@html:- 42
: @@)}}}
: exported as:

* :results code, contents as elisp

#+CALL: demo("code",contents="(quote (+ 1 2))")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{(quote (+ 1 2) )}
: export backend: ascii
: result: src_emacs-lisp[:results code]{(quote (+ 1 2) )} {{{results(src_emacs-lisp[]{(+ 1 2)
: })}}}
: exported as:
: src_emacs-lisp[]{(+ 1 2) }

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> I've attached three patches and two files that show the behavior under
> the current master (12 Jan 2015,
> e0879b03d08bb4acc663084076370482f61e8698) and under the patched
> version.

Thank you. Some comments follow.

> With the patches, inline source block results can be removed by
> re-executing the source block if they are wrapped in
> a `{{{results(...)}}}' macro. The schema for the RESULT-PARAMS is as
> follows, but see the examples for caveats:
>
>   | Param           | Example output                    |
>   |-----------------+-----------------------------------+
>   | default/replace | {{{results(=42=)}}}               |
>   | list            | \n: - 42\n\n                      |
>   | raw             | 42                                |
>   | drawer/wrap     | {{{results(42)}}}                 |
>   | org             | {{{results(src_org{...})}}}       |
>   | html            | {{{results(@@html:...@@)}}}       |
>   | latex           | {{{results(@@latex:...@@)}}}      |
>   | code            | {{{results(src_emacs-lisp{...})}}}|
>   | table           | \n| 42 |\n\n                      |
>   |-----------------+-----------------------------------+

I don't think inline Babel blocks should be able to generate lists or
tables. Org cannot contain inline lists or tables. If you need a real
table or list, a regular Babel call will do.

I suggest to ignore :results table and :results list, or even return an
error, since this is bound to breaking the document structure.

> The `results' macro is hard coded to wrap `value' except when list,
> table, or raw is specified as a RESULT-PARAM or when (listp value).
> And obviously, :file

I thought :file produced {{{results([[file:...]]}}} ?

> * lisp/ob-core.el (org-babel-insert-result): Delete any `results'
>   macro following current inline src block; insert current value in
>   'results' macro possibly wrapping RESULT in an export snippet or
>   inline source block first. Protect commas and backslash commas in the
>   RESULT with backslashes if the macro form is used.

I think the "protect commas and backslashes commas" should be factored
out of "ob-core.el" (and "org-element.el") and moved into
"org-macro.el".

> +By default RESULT is inserted after the end of the current source
> +block.  The RESULT of an inline source block usually will be
> +wrapped inside a `results' macro and placed on the same line as
> +the inline source block. The macro is stripped upon

Two spaces.

> +export. Multiline and non-scalar RESULTS from inline source
> +blocks are fragile and should be avoided. With optional argument

Ditto.

> +RESULT-PARAMS controls insertion of results in the org-mode file.

Org mode file.

> +		 ;; escape commas, e.g. {{{results(a\,b)}}} 
> +		 ((and inlinep
> +		       (not (member "raw" result-params)))
> +		  (goto-char beg)
> +		  (insert
> +		   ;; Escape commas and preceding backslash per
> +		   ;;  (info "(org) Macro replacement").
> +		   (replace-regexp-in-string
> +		    "\\(\\\\*\\)\\(,\\)"
> +		    (lambda (str)
> +		      (let ((len (length (match-string 1 str))))
> +			(concat (make-string (* 2 (/ len 2)) ?\\) "\\,")))
> +		    result nil t)))

See remark about factoring it out.

> +(defun org-babel-remove-inline-result ()
> +  "Remove the result of the current inline-src-block if it is
> +  wrapped in a `results' macro and trim extraneous leading whitespace."

Docstring's first sentence has to fit on a single line.

> +  (let ((el (org-element-context)) post-blank)

(let* ((el (org-element-context))
       (post-blank (org-element-property :post-blank el)))
 ...)

> +    (when (eq (org-element-type el) 'inline-src-block)
> +      (save-excursion

`org-with-wide-buffer' is better: results might be outside the narrowed
part of the buffer.

> +	(setq post-blank (org-element-property :post-blank el))

See above.

> +        (goto-char (org-element-property :end el))
> +        (setq el (org-element-context))

(let ((el (org-element-context))))

> +        (when (and (eq (org-element-type el) 'macro)
> +                   (equal (org-element-property :key el) "results"))

Nitpick: `equal' => `string='


Regards,

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Chuck,

Thanks for the patches.

I agree with Nicolas about the issue of multi-line results for inline
blocks.  I think he already raised any comments I would have made about
the code.  Additional comments about broader issues:

2015ko urtarrilak 12an, "Charles C. Berry"-ek idatzi zuen:
>  (defun org-babel-insert-result
>    (result &optional result-params info hash indent lang)
>    "Insert RESULT into the current buffer.

It’s not strictly speaking relevant to your patch, but it would be good to
put a couple sentences about the :wrap header arg in this docstring.  I
think it could go at the end, and read something like “Specifying a :wrap
header argument will wrap the result in a #+begin_/#+end_ block or (for
inline source blocks) an export snippet whose type is determined by the
value of the argument (with a default of "results").  The specification of
:wrap overrides the :result values described above.”

[...]

>  drawer -- results are added directly to the Org-mode file as with
> -          \"raw\", but are wrapped in a RESULTS drawer, allowing
> -          them to later be replaced or removed automatically.
> +          \"raw\", but are wrapped in a RESULTS drawer or results
> +          macro, allowing them to later be replaced or removed
> +          automatically.
>

I think it’s worth changing the name of this option, now that it no
longer creates a drawer in all cases.  Perhaps raw-wrap could be used.
(Of course, drawer would be retained as a backwards compatibility alias,
preferably with a comment in the code describing when and why it was
deprecated.)  This would also require changes to the manual.

[...]

>  		    (funcall wrap (concat "#+BEGIN_" name)
> -			     (concat "#+END_" (car (org-split-string name))))))
> +			     (concat "#+END_" (car (org-split-string name)))
> +			     nil nil (concat "{{{results(@@" name ":") "@@)}}}")))

I think it would be more flexible to allow :wrap to change the name of
the macro which is used, rather than to insert an export snippet.  If a
custom export snippet is desired, this could be specified via the custom
macro name – but the macro could also supply other special formatting.
(This suggestion would impact the wording of the docstring addition
suggested above.)  WDYT?

Especially the first two of these suggestions are things I (or anyone)
could implement in further patches, if you’d rather not take them on at
present.

Thanks,
 
-- 
Aaron Ecay

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

>>  		    (funcall wrap (concat "#+BEGIN_" name)
>> -			     (concat "#+END_" (car (org-split-string name))))))
>> +			     (concat "#+END_" (car (org-split-string name)))
>> +			     nil nil (concat "{{{results(@@" name ":") "@@)}}}")))
>
> I think it would be more flexible to allow :wrap to change the name of
> the macro which is used, rather than to insert an export snippet.  If a
> custom export snippet is desired, this could be specified via the custom
> macro name – but the macro could also supply other special formatting.
> (This suggestion would impact the wording of the docstring addition
> suggested above.)  WDYT?

It would be more flexible, but it would also defeat the whole point of
the "results" macro, that is to be able to mark /unambiguously/ the
output of an inline block. Indeed, even if you can get the name of the
macro from the parameter, you cannot be sure the macro was generated by
the code block, unlike to a results macro.

Also, I don't think we really need this flexibility since any twist to
the output can be made at the Babel level, or even using
`org-babel-inline-result-wrap'.


Regards,

-- 
Nicolas Goaziou

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Nicolas,

2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen:
> It would be more flexible, but it would also defeat the whole point of
> the "results" macro, that is to be able to mark /unambiguously/ the
> output of an inline block. Indeed, even if you can get the name of the
> macro from the parameter, you cannot be sure the macro was generated by
> the code block, unlike to a results macro.

Well, you could examine the code block’s :wrap header arg to determine
what kind of macro it generates, rather than hardcoding “results.”
(This would break when :wrap’s value was changed, though).

Probably a better solution is that the results macro could wrap the
custom macro:

{{{results({{{mymacro(foo)}}})}}}

> 
> Also, I don't think we really need this flexibility since any twist to
> the output can be made at the Babel level, or even using
> `org-babel-inline-result-wrap'.

o-b-inline-result-wrap can’t be specified on a per-block basis like
header args can.  And doing it within babel would lead to extra
verbosity.  As an example use case, I sometimes write things like:

src_R{round(100*78/7065,2)}

What I’m really interested in is the value 100*78/7065,¹ but I don’t want
it spilling its many decimal places into the exported document (I don’t
particularly mind them in the org file).  I think the following would be a
better way of writing things like this, since it separates the presentation
(round to two decimal places) from the content (100*78/7065):

src_R[:wrap round2]{100*78/7065}

I would write a round2 macro to arrange the rounding.  (round2 and
round0/truncate would probably cover 90+% of my use of inline R
blocks).  For latex, this would use one of the packages like siunitx
or pgfplots which offer number formatting (including other fancy
options like scientific notation for large numbers).  For other
backends, I’d probably use an eval-type macro to do the rounding in
elisp.

¹ This is just a particularly simple example; often the value is not
just the result of some arithmetic, but rather a coefficient extracted
from a statistical model by a series of function calls etc.

Thanks,

-- 
Aaron Ecay

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

Aaron Ecay <aaronecay@gmail.com> writes:

> 2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen:
>> It would be more flexible, but it would also defeat the whole point of
>> the "results" macro, that is to be able to mark /unambiguously/ the
>> output of an inline block. Indeed, even if you can get the name of the
>> macro from the parameter, you cannot be sure the macro was generated by
>> the code block, unlike to a results macro.
>
> Well, you could examine the code block’s :wrap header arg to determine
> what kind of macro it generates, rather than hardcoding “results.”
> (This would break when :wrap’s value was changed, though).

As I said above, even if you read :wrap parameter, this is ambiguous,
since the use can insert any "foo" macro after a ":wrap foo":

  src_emacs-lisp[:wrap foo]{(+ 1 1)} {{{foo(this is something else)}}}

> Probably a better solution is that the results macro could wrap the
> custom macro:
>
> {{{results({{{mymacro(foo)}}})}}}

You cannot nest macros.

>> Also, I don't think we really need this flexibility since any twist to
>> the output can be made at the Babel level, or even using
>> `org-babel-inline-result-wrap'.
>
> o-b-inline-result-wrap can’t be specified on a per-block basis like
> header args can.  And doing it within babel would lead to extra
> verbosity.  As an example use case, I sometimes write things like:
>
> src_R{round(100*78/7065,2)}
>
> What I’m really interested in is the value 100*78/7065,¹ but I don’t want
> it spilling its many decimal places into the exported document (I don’t
> particularly mind them in the org file).  I think the following would be a
> better way of writing things like this, since it separates the presentation
> (round to two decimal places) from the content (100*78/7065):
>
> src_R[:wrap round2]{100*78/7065}
>
> I would write a round2 macro to arrange the rounding.  (round2 and
> round0/truncate would probably cover 90+% of my use of inline R
> blocks).  For latex, this would use one of the packages like siunitx
> or pgfplots which offer number formatting (including other fancy
> options like scientific notation for large numbers).  For other
> backends, I’d probably use an eval-type macro to do the rounding in
> elisp.

No matter how appealing this feature sounds to you, it would be flawed
and is not strictly necessary. You probably can use some Babel code
instead.

Note that your hypothetical code would sometimes fail, too, as regular
macros are expanded before Babel code is executed. IOW, macros can
produce Babel code, but not the other way (at least not consistently).


Regards,

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Nicolas,

2015ko urtarrilak 18an, Nicolas Goaziou-ek idatzi zuen:
> 
> Aaron Ecay <aaronecay@gmail.com> writes:
> 
>> 2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen:
>>> It would be more flexible, but it would also defeat the whole point of
>>> the "results" macro, that is to be able to mark /unambiguously/ the
>>> output of an inline block. Indeed, even if you can get the name of the
>>> macro from the parameter, you cannot be sure the macro was generated by
>>> the code block, unlike to a results macro.
>> 
>> Well, you could examine the code block’s :wrap header arg to determine
>> what kind of macro it generates, rather than hardcoding “results.”
>> (This would break when :wrap’s value was changed, though).
> 
> As I said above, even if you read :wrap parameter, this is ambiguous,
> since the use can insert any "foo" macro after a ":wrap foo":
> 
>   src_emacs-lisp[:wrap foo]{(+ 1 1)} {{{foo(this is something else)}}}
> 
>> Probably a better solution is that the results macro could wrap the
>> custom macro:
>> 
>> {{{results({{{mymacro(foo)}}})}}}
> 
> You cannot nest macros.

OK, I didn’t know that.

> 

[...]

> You probably can use some Babel code instead.

Indeed, it looks like the system I had in mind wouldn’t work very well.
Thanks for this suggestion, I’ll look into it.

Thanks,

-- 
Aaron Ecay

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1717 bytes --]

On Fri, 16 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> I've attached three patches and two files that show the behavior under
>> the current master (12 Jan 2015,
>> e0879b03d08bb4acc663084076370482f61e8698) and under the patched
>> version.
>
> Thank you. Some comments follow.
>

[snip]

>
> I don't think inline Babel blocks should be able to generate lists or
> tables. Org cannot contain inline lists or tables. If you need a real
> table or list, a regular Babel call will do.
>
> I suggest to ignore :results table and :results list, or even return an
> error, since this is bound to breaking the document structure.
>

OK. Now those cases (and some others) insert `*Inline error:' and a
comment as to what the error is and ignore the actual value.

Based on my own experience, I thought it best to allow Babel to run 
without stopping when there are problems with inline src blocks rather 
than stop with an error.

[snip]

>
> I think the "protect commas and backslashes commas" should be factored
> out of "ob-core.el" (and "org-element.el") and moved into
> "org-macro.el".
>

OK.

I hope the approach I took modifies `org-macro-expand'.

The "as-is" template returns the macro element :value stripped of the 
leading "{{{<name>(" and the trailing "[\n]?)}}}".  The template allows 
macros that mark text - possibly including commas - but do not modify it.

I am not sure why you mentioned org-element.el.

[snip]

Other comments from Nicolas 16 Jan email are addresed in the attached 
patches.

These patches address inline babel calls and apply the same logic to them.

A file with examples is attached.

n.b. the patch prefix numbers are 0002-0005.

HTH,

Chuck

[-- Attachment #2: ob-core.el patch --]
[-- Type: TEXT/PLAIN, Size: 12365 bytes --]

From 28e91c6dc718bef24b2e960864f458da046df225 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:45:01 -0800
Subject: [PATCH 2/5] lisp/ob-core.el: Inline source block / babel call results
 are replaceable

 * lisp/ob-core.el (org-babel-insert-result): Delete any `results'
   macro following current inline src block; insert current value in
   'results' macro possibly wrapping RESULT in an export snippet or
   inline source block first.

  * lisp/ob-core.el (org-babel-remove-inline-result): Delete results
     of current inline src block or inline babel call if it is wrapped
     in a "{{{results(.*)}}}" macro call.

* lisp/ob-core.el (org-babel-get-lob-one-liner-matches): Ensure that
  the point ends up on the same line as, and just before, `call_' when
  searching backward.

Inline source block or babel call results can be removed by
re-executing the source blocks or babel calls if they are wrapped in a
`{{{results(...)}}}' macro.  The schema for the RESULT-PARAMS is:

  |-----------------+--------------------------------------------------|
  | Param           | Example output                                   |
  |-----------------+--------------------------------------------------|
  | default/replace | {{{results(42)}}}                     	       |
  | raw             | 42                                    	       |
  | drawer          | {{{results(42)}}}                     	       |
  | org             | {{{results(src_org{...})}}}           	       |
  | html            | {{{results(@@html:...@@)}}}           	       |
  | latex           | {{{results(@@latex:...@@)}}}          	       |
  | code            | {{{results(src_xxx{...})}}}           	       |
  | file            | {{{results([[file:something.pdf]])}}} 	       |
  | table           | {{{results(*Inline error:* `:results table')}}}  |
  | list            | {{{results(*Inline error:* `:results list')}}}   |
  |-----------------+--------------------------------------------------|

 where the default is `src_emacs{42}' and subsequent rows give the `:results' arg.

The `:wrap something' header arg gives an effect similar to `:results
 html' or `:results latex'.

Results that are lists or tables or strings with more than one line
(excepting a trailing "\n") output *Inline error:* messages wrapped in
the `results' macro.

On export, the `results' macro is stripped away before the buffer is
parsed.
---
 lisp/ob-core.el | 116 +++++++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 85 insertions(+), 31 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 93fcb2a..63ccabc 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -251,7 +251,8 @@ Returns non-nil if match-data set"
 Returns non-nil if match-data set"
   (save-excursion
     (unless (= (point) (point-at-bol)) ;; move before inline block
-      (re-search-backward "[ \f\t\n\r\v]" nil t))
+      (re-search-backward "\\([^[:alpha:]]\\|[ \f\t\n\r\v]\\)call_" nil t)
+      (goto-char (match-end 1)))
     (if (looking-at org-babel-inline-lob-one-liner-regexp)
 	t
       nil)))
@@ -2073,13 +2074,18 @@ If the path of the link is a file path it is expanded using
 (defun org-babel-insert-result
   (result &optional result-params info hash indent lang)
   "Insert RESULT into the current buffer.
-By default RESULT is inserted after the end of the
-current source block.  With optional argument RESULT-PARAMS
-controls insertion of results in the org-mode file.
+By default RESULT is inserted after the end of the current source
+block.  The RESULT of an inline source block usually will be
+wrapped inside a `results' macro and placed on the same line as
+the inline source block.  The macro is stripped upon
+export.  Multiline and non-scalar RESULTS from inline source
+blocks are fragile and should be avoided. With optional argument
+RESULT-PARAMS controls insertion of results in the Org mode file.
 RESULT-PARAMS can take the following values:
 
 replace - (default option) insert results after the source block
-          replacing any previously inserted results
+          or inline source block replacing any previously
+          inserted results
 
 silent -- no results are inserted into the Org-mode buffer but
           the results are echoed to the minibuffer and are
@@ -2096,8 +2102,9 @@ raw ----- results are added directly to the Org-mode file.  This
           formatted text.
 
 drawer -- results are added directly to the Org-mode file as with
-          \"raw\", but are wrapped in a RESULTS drawer, allowing
-          them to later be replaced or removed automatically.
+          \"raw\", but are wrapped in a RESULTS drawer or results
+          macro, allowing them to later be replaced or removed
+          automatically.
 
 org ----- results are added inside of a \"src_org{}\" or \"#+BEGIN_SRC
           org\" block depending on whether the current source block is
@@ -2105,13 +2112,15 @@ org ----- results are added inside of a \"src_org{}\" or \"#+BEGIN_SRC
           but Org syntax here will be discarded when exporting the
           file.
 
-html ---- results are added inside of a #+BEGIN_HTML block.  This
-          is a good option if you code block will output html
-          formatted text.
+html ---- results are added inside of a #+BEGIN_HTML block or
+          html export snippet depending on whether the current
+          source block is inline or not.  This is a good option
+          if you code block will output html formatted text.
 
-latex --- results are added inside of a #+BEGIN_LATEX block.
-          This is a good option if you code block will output
-          latex formatted text.
+latex --- results are added inside of a #+BEGIN_LATEX block or
+          latex export snippet depending on whether the current
+          source block is inline or not.  This is a good option
+          if you code block will output latex formatted text.
 
 code ---- the results are extracted in the syntax of the source
           code of the language being evaluated and are added
@@ -2138,11 +2147,20 @@ code ---- the results are extracted in the syntax of the source
 		(when (or (org-babel-get-inline-src-block-matches)
 			  (org-babel-get-lob-one-liner-matches))
 		  (goto-char (match-end 0))
-		  (insert (if (listp result) "\n" " "))
+		  (insert " ")
 		  (point))))
-	     (existing-result (unless inlinep
+	     (existing-result (if inlinep
+				  (org-babel-remove-inline-result)
 				(org-babel-where-is-src-block-result
 				 t info hash indent)))
+	     (bad-inline-p
+	      (when inlinep
+		(or
+		 (and (member "table" result-params) "`:results table'")
+		 (and (listp result) "list result")
+		 (and (string-match-p "\n.+" result) "multiline result")
+		 (and (member "list" result-params) "`:results list'")
+		 )))
 	     (results-switches
 	      (cdr (assoc :results_switches (nth 2 info))))
 	     (visible-beg (copy-marker (point-min)))
@@ -2179,7 +2197,12 @@ code ---- the results are extracted in the syntax of the source
 		 ((member "prepend" result-params)))) ; already there
 	      (setq results-switches
 		    (if results-switches (concat " " results-switches) ""))
-	      (let ((wrap (lambda (start finish &optional no-escape no-newlines)
+	      (let ((wrap (lambda (start finish &optional no-escape no-newlines
+					 inline-start inline-finish)
+			    (when inlinep
+			      (setq start inline-start)
+			      (setq finish inline-finish)
+			      (setq no-newlines t))
 			    (goto-char end)
 			    (insert (concat finish (unless no-newlines "\n")))
 			    (goto-char beg)
@@ -2194,8 +2217,13 @@ code ---- the results are extracted in the syntax of the source
 		(cond
 		 ;; do nothing for an empty result
 		 ((null result))
+		 ;; illegal inline result or params
+		 (bad-inline-p
+		  (goto-char beg)
+		  (insert "{{{results(*Inline error:* " bad-inline-p ")}}}" ))
 		 ;; insert a list if preferred
 		 ((member "list" result-params)
+		  (goto-char beg)
 		  (insert
 		   (org-babel-trim
 		    (org-list-to-generic
@@ -2225,37 +2253,45 @@ code ---- the results are extracted in the syntax of the source
 		(setq end (point-marker))
 		;; possibly wrap result
 		(cond
+		 (bad-inline-p) ;; do nothing
 		 ((assoc :wrap (nth 2 info))
 		  (let ((name (or (cdr (assoc :wrap (nth 2 info))) "RESULTS")))
 		    (funcall wrap (concat "#+BEGIN_" name)
-			     (concat "#+END_" (car (org-split-string name))))))
+			     (concat "#+END_" (car (org-split-string name)))
+			     nil nil (concat "{{{results(@@" name ":") "@@)}}}")))
 		 ((member "html" result-params)
-		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML"))
-		 ((member "latex" result-params)
-		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX"))
+		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML" nil nil
+			   "{{{results(@@html:" "@@)}}}"))
+		 ((member "latex" result-params) 
+		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX" nil nil
+			   "{{{results(@@latex:" "@@)}}}"))
 		 ((member "org" result-params)
 		  (goto-char beg) (if (org-at-table-p) (org-cycle))
-		  (if inlinep
-		      (funcall wrap "src_org{" "}" nil t)
-		      (funcall wrap "#+BEGIN_SRC org" "#+END_SRC")))
+		  (funcall wrap "#+BEGIN_SRC org" "#+END_SRC" nil nil
+			   "{{{results(src_org{" "})}}}"))
 		 ((member "code" result-params)
 		  (let ((lang (or lang "none")))
-		    (if inlinep
-			(funcall wrap (format "src_%s[%s]{" lang results-switches)
-				 "}" nil t)
-			(funcall wrap (format "#+BEGIN_SRC %s%s" lang results-switches)
-				 "#+END_SRC"))))
+		    (funcall wrap (format "#+BEGIN_SRC %s%s" lang results-switches)
+			     "#+END_SRC" nil nil
+			     (format "{{{results(src_%s[%s]{" lang results-switches)
+			     "})}}}")))
 		 ((member "raw" result-params)
 		  (goto-char beg) (if (org-at-table-p) (org-cycle)))
 		 ((or (member "drawer" result-params)
 		      ;; Stay backward compatible with <7.9.2
 		      (member "wrap" result-params))
 		  (goto-char beg) (if (org-at-table-p) (org-cycle))
-		  (funcall wrap ":RESULTS:" ":END:" 'no-escape))
+		  (funcall wrap ":RESULTS:" ":END:" 'no-escape nil
+			   "{{{results(" ")}}}"))
+		 ((and inlinep (member "file" result-params))
+		  (funcall wrap nil nil nil nil "{{{results(" ")}}}"))
 		 ((and (not (funcall proper-list-p result))
 		       (not (member "file" result-params)))
-		  (org-babel-examplify-region beg end results-switches)
-		  (setq end (point)))))
+		  (let ((org-babel-inline-result-wrap
+			 ;; Hard code {{{results(...)}}} on top of customization.
+			 (format "{{{results(%s)}}}" org-babel-inline-result-wrap)))
+		    (org-babel-examplify-region beg end results-switches)
+		    (setq end (point))))))
 	      ;; possibly indent the results to match the #+results line
 	      (when (and (not inlinep) (numberp indent) indent (> indent 0)
 			 ;; in this case `table-align' does the work for us
@@ -2283,6 +2319,24 @@ code ---- the results are extracted in the syntax of the source
 	   (if keep-keyword (1+ (match-end 0)) (1- (match-beginning 0)))
 	   (progn (forward-line 1) (org-babel-result-end))))))))
 
+(defun org-babel-remove-inline-result ()
+  "Remove the result of the current inline-src-block.
+The result must be wrapped in a `results' macro to be
+  removed. Extraneous leading whitespace is trimmed."
+  (let* ((el (org-element-context))
+	 (post-blank (org-element-property :post-blank el)))
+    (when (member (org-element-type el) '(inline-src-block inline-babel-call))
+      (org-with-wide-buffer
+        (goto-char (org-element-property :end el))
+        (let  ((el (org-element-context)))
+	  (when (and (eq (org-element-type el) 'macro)
+		     (string= (org-element-property :key el) "results"))
+	    (delete-region ; And (only) extra leading whitespace.
+	     (- (org-element-property :begin el)
+		(- post-blank 1))
+	     (- (org-element-property :end el)
+		(org-element-property :post-blank el)))))))))
+
 (defun org-babel-remove-result-one-or-many (x)
   "Remove the result of the current source block.
 If called with a prefix argument, remove all result blocks
-- 
1.9.3 (Apple Git-50)


[-- Attachment #3: ob-exp.el patch --]
[-- Type: TEXT/PLAIN, Size: 1321 bytes --]

From 6bc9acb7376ea16fe149bf4749fa56387ce526cf Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:49:57 -0800
Subject: [PATCH 3/5] ob-exp.el: Enable removal of {{{results(...)}}}

* ob-exp.el (org-babel-do-export): `clean' lambda form removes inline
  results wrapped in `results{{{(' `)}}}' by calling
  `org-babel-remove-inline-result'.
---
 lisp/ob-exp.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index edb889c..afe6cd9 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -315,7 +315,9 @@ The function respects the value of the :exports header argument."
   (let ((silently (lambda () (let ((session (cdr (assoc :session (nth 2 info)))))
 			       (when (not (and session (equal "none" session)))
 				 (org-babel-exp-results info type 'silent)))))
-	(clean (lambda () (unless (eq type 'inline) (org-babel-remove-result info)))))
+	(clean (lambda () (if (eq type 'inline)
+			      (org-babel-remove-inline-result info)
+			    (org-babel-remove-result info)))))
     (case (intern (or (cdr (assoc :exports (nth 2 info))) "code"))
       ('none (funcall silently) (funcall clean) "")
       ('code (funcall silently) (funcall clean) (org-babel-exp-code info type))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #4: ox.el patch --]
[-- Type: TEXT/PLAIN, Size: 1002 bytes --]

From 66b61c0e68af63f41f52c37a3ee9bc5488670889 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Thu, 13 Nov 2014 20:55:36 -0800
Subject: [PATCH 4/5] lisp/ox.el: Enable removable inline src results

* lisp/ox.el: (org-export-as): Treat `results' as an `identity' macro
  with one argument - possibly including commas - after Babel executes.
---
 lisp/ox.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 8880e10..1e85a36 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2884,7 +2884,8 @@ Return code as a string."
 		;; EMAIL is not a parsed keyword: store it as-is.
 		(cons "email" (or (plist-get info :email) ""))
 		(cons "title"
-		      (org-element-interpret-data (plist-get info :title))))
+		      (org-element-interpret-data (plist-get info :title)))
+		(cons "results" "as-is"))
 	  'finalize)
 	 ;; Parse buffer.
 	 (setq tree (org-element-parse-buffer nil visible-only))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #5: org-macro.el patch --]
[-- Type: TEXT/PLAIN, Size: 1518 bytes --]

From a879760d52cdaa235dcb3ef3ee601643ae8d4fe2 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Sun, 18 Jan 2015 16:27:31 -0800
Subject: [PATCH 5/5] org-macro.el: Implement an `identity' macro

* lisp/org-macro.el (org-macro-expand): The "as-is" template returns
  the macro element :value stripped of the leading "{{{<name>(" and
  the trailing "[\n]?)}}}".  The template allows macros that mark text
  - possibly including commas - but do not modify it.
---
 lisp/org-macro.el | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 923e377..8e8614b 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -150,10 +150,15 @@ default value.  Return nil if no template was found."
                           ""))
                     template nil 'literal)))
         ;; VALUE starts with "(eval": it is a s-exp, `eval' it.
-        (when (string-match "\\`(eval\\>" value)
+        (cond
+	 ((string-match "\\`(eval\\>" value)
           (setq value (eval (read value))))
+	 ((string= "as-is" value)
+	  (setq value (replace-regexp-in-string
+		       "^{{{[[:alpha:]]+(\\(.*\\)\n?)}}}$" "\\1"
+		       (org-element-property :value macro)))))
         ;; Return string.
-        (format "%s" (or value ""))))))
+	(format "%s" (or value ""))))))
 
 (defun org-macro-replace-all (templates &optional finalize)
   "Replace all macros in current buffer by their expansion.
-- 
1.9.3 (Apple Git-50)


[-- Attachment #6: some examples --]
[-- Type: TEXT/PLAIN, Size: 4947 bytes --]

Demonstrate inline-src block-behavior and the {{{results( )}}} macro.

The `demo' src block sets up an inline-src-block, calls it, then
exports the result. The output is as follows:

- inline-src-block :: inline-src-block with headers and content.
- export backend :: Which backend was used to render the result.
- result :: What the ~*.org~ buffer looks looks like after babel
     executes the inline-src-block.
- exported as :: Show the exported version (starting on the next line). 

* :results replace (default) 

#+name: demo
#+BEGIN_SRC emacs-lisp :var str="replace" bkend="ascii" contents="42"
  (let ((cmd (format "src_emacs-lisp[:results %s]{%s}" str contents)))
    (concat "inline-src-block: " cmd "\nexport backend: " bkend 
            "\nresult: " (with-temp-buffer
                           (insert cmd)
                           (org-babel-execute-buffer)
                           (buffer-string))
            "\nexported as:\n"
            (org-export-string-as cmd (intern bkend) t)))
#+END_SRC

#+RESULTS: demo
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} {{{results(=42=)}}}
: exported as:
: `42'


#+CALL: demo("replace")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} {{{results(=42=)}}}
: exported as:
: `42'

* :results html under html backend

#+CALL: demo("html","html")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html]{42}
: export backend: html
: result: src_emacs-lisp[:results html]{42} {{{results(@@html:42@@)}}}
: exported as:
: <p>
: 42</p>

* :results html under latex backend

#+CALL: demo("html","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html]{42}
: export backend: latex
: result: src_emacs-lisp[:results html]{42} {{{results(@@html:42@@)}}}
: exported as:

* :results latex under latex backend

#+CALL: demo("latex","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results latex]{42}
: export backend: latex
: result: src_emacs-lisp[:results latex]{42} {{{results(@@latex:42@@)}}}
: exported as:
: 42

* :results replace :wrap ascii

#+CALL: demo("replace :wrap ascii","ascii")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace :wrap ascii]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace :wrap ascii]{42} {{{results(@@ascii:42@@)}}}
: exported as:
: 42

* :results raw

#+CALL: demo("raw")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results raw]{42}
: export backend: ascii
: result: src_emacs-lisp[:results raw]{42} 42
: exported as:
: 42

* :results drawer

Same as default.

#+CALL: demo("drawer")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results drawer]{42}
: export backend: ascii
: result: src_emacs-lisp[:results drawer]{42} {{{results(42)}}}
: exported as:
: 42

* :results org

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("org")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results org]{42}
: export backend: ascii
: result: src_emacs-lisp[:results org]{42} {{{results(src_org{42})}}}
: exported as:
: `42'

* :results code

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("code")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{42}
: export backend: ascii
: result: src_emacs-lisp[:results code]{42} {{{results(src_emacs-lisp[]{42})}}}
: exported as:
: `42'

* :results list

Lists and tables should be avoided for inline-src-blocks, but for
completeness some are listed here.

#+CALL: demo("list")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results list]{42}
: export backend: ascii
: result: src_emacs-lisp[:results list]{42} {{{results(*Inline error:* `:results list')}}}
: exported as:
: *Inline error:* `:results list'

* :results table

#+CALL: demo("table")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results table]{42}
: export backend: ascii
: result: src_emacs-lisp[:results table]{42} {{{results(*Inline error:* `:results table')}}}
: exported as:
: *Inline error:* `:results table'

* :results replace, proper list as content

Proper lists become tables.

#+CALL: demo(contents="\'(42)")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{'(42) }
: export backend: ascii
: result: src_emacs-lisp[:results replace]{'(42) } {{{results(*Inline error:* list result)}}}
: exported as:
: *Inline error:* list result

* :results code, contents as elisp

#+CALL: demo("code",contents="(quote (+ 1 2))")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{(quote (+ 1 2) )}
: export backend: ascii
: result: src_emacs-lisp[:results code]{(quote (+ 1 2) )} {{{results(src_emacs-lisp[]{(+ 1 2)
: })}}}
: exported as:
: src_emacs-lisp[]{(+ 1 2) }

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

Thanks for the patches. Here's another round of comments.

> OK. Now those cases (and some others) insert `*Inline error:' and a
> comment as to what the error is and ignore the actual value.
>
> Based on my own experience, I thought it best to allow Babel to run
> without stopping when there are problems with inline src blocks rather
> than stop with an error.

We already stop with an error for missing footnotes definitions or
missing macro templates. I'm not totally against your suggestion, but
I think it would be better to follow this.

> I hope the approach I took modifies `org-macro-expand'.
>
> The "as-is" template returns the macro element :value stripped of the
> leading "{{{<name>(" and the trailing "[\n]?)}}}".  The template
> allows macros that mark text - possibly including commas - but do not
> modify it.

Actually I preferred the previous implementation because this one adds
another level of indirection, the (undocumented) "as-is" template.
"results" -> "$1" was more elegant.

We just need an `org-macro-protect-argument' function. I can do the
refactoring if you want.

> I am not sure why you mentioned org-element.el.

The snippet you were using comes from `org-element-macro-parser', in
"org-element.el". If two locations use the same snippet, it is better to
refactor it.

>  (defun org-babel-insert-result
>    (result &optional result-params info hash indent lang)
>    "Insert RESULT into the current buffer.
> -By default RESULT is inserted after the end of the
> -current source block.  With optional argument RESULT-PARAMS
> -controls insertion of results in the org-mode file.
> +By default RESULT is inserted after the end of the current source
> +block.  The RESULT of an inline source block usually will be
> +wrapped inside a `results' macro and placed on the same line as
> +the inline source block.  The macro is stripped upon
> +export.  Multiline and non-scalar RESULTS from inline source
> +blocks are fragile and should be avoided. With optional argument
                                            ^^^
Two spaces needed.

> +RESULT-PARAMS controls insertion of results in the Org mode file.
>  RESULT-PARAMS can take the following values:

"It can take"? Or, "The following values are allowed"...

> +	     (bad-inline-p
> +	      (when inlinep
> +		(or
> +		 (and (member "table" result-params) "`:results table'")
> +		 (and (listp result) "list result")
> +		 (and (string-match-p "\n.+" result) "multiline result")
> +		 (and (member "list" result-params) "`:results list'")
> +		 )))

No parenthesis on their own line.

> +(defun org-babel-remove-inline-result ()
> +  "Remove the result of the current inline-src-block.
> +The result must be wrapped in a `results' macro to be
> +  removed. Extraneous leading whitespace is trimmed."
> +  (let* ((el (org-element-context))
> +	 (post-blank (org-element-property :post-blank el)))
> +    (when (member (org-element-type el) '(inline-src-block inline-babel-call))

`member' -> `memq'


Regards,

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

On Mon, 19 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
> Thanks for the patches. Here's another round of comments.
>
>> OK. Now those cases (and some others) insert `*Inline error:' and a
>> comment as to what the error is and ignore the actual value.
>>
>> Based on my own experience, I thought it best to allow Babel to run
>> without stopping when there are problems with inline src blocks rather
>> than stop with an error.
>
> We already stop with an error for missing footnotes definitions or
> missing macro templates. I'm not totally against your suggestion, but
> I think it would be better to follow this.
>

OK. I'll try it. If there are howls of pain from users (including my own 
howls), it will be easy enough to fix.

>> I hope the approach I took modifies `org-macro-expand'.
>>
>> The "as-is" template returns the macro element :value stripped of the
>> leading "{{{<name>(" and the trailing "[\n]?)}}}".  The template
>> allows macros that mark text - possibly including commas - but do not
>> modify it.
>
> Actually I preferred the previous implementation because this one adds
> another level of indirection, the (undocumented) "as-is" template.
> "results" -> "$1" was more elegant.
>
> We just need an `org-macro-protect-argument' function. I can do the
> refactoring if you want.
>

This is probably the shortest path. I'd apprecaite it if you would 
refactor that part.

>> I am not sure why you mentioned org-element.el.
>
> The snippet you were using comes from `org-element-macro-parser', in
> "org-element.el". If two locations use the same snippet, it is better to
> refactor it.
>

This is where I get mixed up. I'm not sure exactly what the refactoring 
amounts to.

So I guess I need to see what the refactoring amounts to, then deal with 
the rest of your comments.

Thanks for your patience!

Chuck

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> This is probably the shortest path. I'd apprecaite it if you would
> refactor that part.

I implemented `org-macro-escape-arguments' which can replace your
initial snippet:

+		   ;; Escape commas and preceding backslash per
+		   ;;  (info "(org) Macro replacement").
+		   (replace-regexp-in-string
+		    "\\(\\\\*\\)\\(,\\)"
+		    (lambda (str)
+		      (let ((len (length (match-string 1 str))))
+			(concat (make-string (* 2 (/ len 2)) ?\\) "\\,")))
+		    result nil t)


Regards,

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 507 bytes --]

On Tue, 20 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> This is probably the shortest path. I'd apprecaite it if you would
>> refactor that part.
>
> I implemented `org-macro-escape-arguments' which can replace your
> initial snippet:
>

Nicolas,

Thank you!

I attach 3 patches and a file of usage examples.

Any of `:results list', `:results table', multiline results (after 
stripping a trailing newline), and list results now generates an error.

Best,

Chuck


[-- Attachment #2: ox.el patch --]
[-- Type: TEXT/PLAIN, Size: 969 bytes --]

From b3e1998eb5592a74b7d8d91858bc2da8121d0bf5 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Wed, 21 Jan 2015 18:08:58 -0800
Subject: [PATCH 1/3] lisp/ox.el: Enable removable inline src results

* lisp/ox.el: (org-export-as): Treat `results' as an `identity' macro
  with one argument after Babel executes.
---
 lisp/ox.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 8880e10..3d5c7f2 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -2884,7 +2884,8 @@ Return code as a string."
 		;; EMAIL is not a parsed keyword: store it as-is.
 		(cons "email" (or (plist-get info :email) ""))
 		(cons "title"
-		      (org-element-interpret-data (plist-get info :title))))
+		      (org-element-interpret-data (plist-get info :title)))
+		(cons "results" "$1"))
 	  'finalize)
 	 ;; Parse buffer.
 	 (setq tree (org-element-parse-buffer nil visible-only))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #3: ob-exp.el patch --]
[-- Type: TEXT/PLAIN, Size: 1325 bytes --]

From 8598049ee8f581b0866693c861b0905ef158b951 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Wed, 21 Jan 2015 18:12:51 -0800
Subject: [PATCH 2/3] ob-exp.el: Enable removal of {{{results(...)}}}

* ob-exp.el (org-babel-exp-do-export): `clean' lambda form removes inline
  results wrapped in `results{{{(' `)}}}' by calling
  `org-babel-remove-inline-result'.
---
 lisp/ob-exp.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index edb889c..afe6cd9 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -315,7 +315,9 @@ The function respects the value of the :exports header argument."
   (let ((silently (lambda () (let ((session (cdr (assoc :session (nth 2 info)))))
 			       (when (not (and session (equal "none" session)))
 				 (org-babel-exp-results info type 'silent)))))
-	(clean (lambda () (unless (eq type 'inline) (org-babel-remove-result info)))))
+	(clean (lambda () (if (eq type 'inline)
+			      (org-babel-remove-inline-result info)
+			    (org-babel-remove-result info)))))
     (case (intern (or (cdr (assoc :exports (nth 2 info))) "code"))
       ('none (funcall silently) (funcall clean) "")
       ('code (funcall silently) (funcall clean) (org-babel-exp-code info type))
-- 
1.9.3 (Apple Git-50)


[-- Attachment #4: ob-core.el --]
[-- Type: TEXT/PLAIN, Size: 12729 bytes --]

From c89448e5e6859a6c5c9d5d954470d17b3fdb8b25 Mon Sep 17 00:00:00 2001
From: chasberry <ccberry@ucsd.edu>
Date: Wed, 21 Jan 2015 18:22:07 -0800
Subject: [PATCH 3/3] lisp/ob-core.el: Inline source block / babel call results
 are replaceable

* lisp/ob-core.el (org-babel-insert-result): Delete any `results'
  macro following current inline src block or babel call; insert
  current value in 'results' macro possibly wrapping RESULT in an
  export snippet or inline source block first.

* lisp/ob-core.el (org-babel-remove-inline-result): Delete results of
  current inline src block or inline babel call if it is wrapped in a
  "{{{results(.*)}}}" macro call.

* lisp/ob-core.el (org-babel-get-lob-one-liner-matches): Ensure that
  the point ends up on the same line as, and just before, `call_'
  before setting match-data.
---
 lisp/ob-core.el | 152 ++++++++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 115 insertions(+), 37 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 892c3e3..457a4fd 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -252,8 +252,11 @@ Returns non-nil if match-data set"
   "Set match data if on line of an lob one liner.
 Returns non-nil if match-data set"
   (save-excursion
-    (unless (= (point) (point-at-bol)) ;; move before inline block
-      (re-search-backward "[ \f\t\n\r\v]" nil t))
+    (let* ((el (org-element-context))
+	   (beg (org-element-property :begin el))
+	   (type (org-element-type el)))
+      (when (eq type 'inline-babel-call)
+	(goto-char beg)))
     (if (looking-at org-babel-inline-lob-one-liner-regexp)
 	t
       nil)))
@@ -2063,21 +2066,27 @@ If the path of the link is a file path it is expanded using
 (defun org-babel-insert-result
   (result &optional result-params info hash indent lang)
   "Insert RESULT into the current buffer.
-By default RESULT is inserted after the end of the
-current source block.  With optional argument RESULT-PARAMS
-controls insertion of results in the org-mode file.
-RESULT-PARAMS can take the following values:
+
+By default RESULT is inserted after the end of the current source
+block.  The RESULT of an inline source block usually will be
+wrapped inside a `results' macro and placed on the same line as
+the inline source block.  The macro is stripped upon export.
+Multiline and non-scalar RESULTS from inline source blocks are
+not allowed.  With optional argument RESULT-PARAMS controls
+insertion of results in the Org mode file.  RESULT-PARAMS can
+take the following values:
 
 replace - (default option) insert results after the source block
-          replacing any previously inserted results
+          or inline source block replacing any previously
+          inserted results.
 
 silent -- no results are inserted into the Org-mode buffer but
           the results are echoed to the minibuffer and are
           ingested by Emacs (a potentially time consuming
-          process)
+          process).
 
 file ---- the results are interpreted as a file path, and are
-          inserted into the buffer using the Org-mode file syntax
+          inserted into the buffer using the Org-mode file syntax.
 
 list ---- the results are interpreted as an Org-mode list.
 
@@ -2086,8 +2095,9 @@ raw ----- results are added directly to the Org-mode file.  This
           formatted text.
 
 drawer -- results are added directly to the Org-mode file as with
-          \"raw\", but are wrapped in a RESULTS drawer, allowing
-          them to later be replaced or removed automatically.
+          \"raw\", but are wrapped in a RESULTS drawer or results
+          macro, allowing them to later be replaced or removed
+          automatically.
 
 org ----- results are added inside of a \"src_org{}\" or \"#+BEGIN_SRC
           org\" block depending on whether the current source block is
@@ -2095,20 +2105,39 @@ org ----- results are added inside of a \"src_org{}\" or \"#+BEGIN_SRC
           but Org syntax here will be discarded when exporting the
           file.
 
-html ---- results are added inside of a #+BEGIN_HTML block.  This
-          is a good option if you code block will output html
-          formatted text.
+html ---- results are added inside of a #+BEGIN_HTML block or
+          html export snippet depending on whether the current
+          source block is inline or not.  This is a good option
+          if your code block will output html formatted text.
 
-latex --- results are added inside of a #+BEGIN_LATEX block.
-          This is a good option if you code block will output
-          latex formatted text.
+latex --- results are added inside of a #+BEGIN_LATEX block or
+          latex export snippet depending on whether the current
+          source block is inline or not.  This is a good option
+          if your code block will output latex formatted text.
 
 code ---- the results are extracted in the syntax of the source
           code of the language being evaluated and are added
           inside of a source block with the source-code language
           set appropriately.  Also, source block inlining is
           preserved in this case.  Note this relies on the
-          optional LANG argument."
+          optional LANG argument.
+
+list ---- the results are rendered as a list.  This option not
+          allowed for inline src blocks.
+
+table --- the results are rendered as a table.  This option not
+          allowed for inline src blocks.
+
+INFO may provide the values of these header arguments (in the
+`header-arguments-alist' see the docstring for
+`org-babel-get-src-block-info'):
+
+:file --- the name of the file to which output should be written. 
+
+:wrap --- the effect is similar to `latex' in RESULT-PARAMS but
+          using the argument supplied to specify the export block
+          or snippet type."
+  
   (if (stringp result)
       (progn
         (setq result (org-no-properties result))
@@ -2128,11 +2157,19 @@ code ---- the results are extracted in the syntax of the source
 		(when (or (org-babel-get-inline-src-block-matches)
 			  (org-babel-get-lob-one-liner-matches))
 		  (goto-char (match-end 0))
-		  (insert (if (listp result) "\n" " "))
+		  (insert " ")
 		  (point))))
-	     (existing-result (unless inlinep
+	     (existing-result (if inlinep
+				  (org-babel-remove-inline-result)
 				(org-babel-where-is-src-block-result
 				 t info hash indent)))
+	     (bad-inline-p
+	      (when inlinep
+		(or
+		 (and (member "table" result-params) "`:results table'")
+		 (and (listp result) "list result")
+		 (and (string-match-p "\n." result) "multiline result")
+		 (and (member "list" result-params) "`:results list'"))))
 	     (results-switches
 	      (cdr (assoc :results_switches (nth 2 info))))
 	     (visible-beg (copy-marker (point-min)))
@@ -2169,7 +2206,12 @@ code ---- the results are extracted in the syntax of the source
 		 ((member "prepend" result-params)))) ; already there
 	      (setq results-switches
 		    (if results-switches (concat " " results-switches) ""))
-	      (let ((wrap (lambda (start finish &optional no-escape no-newlines)
+	      (let ((wrap (lambda (start finish &optional no-escape no-newlines
+					 inline-start inline-finish)
+			    (when inlinep
+			      (setq start inline-start)
+			      (setq finish inline-finish)
+			      (setq no-newlines t))
 			    (goto-char end)
 			    (insert (concat finish (unless no-newlines "\n")))
 			    (goto-char beg)
@@ -2184,6 +2226,9 @@ code ---- the results are extracted in the syntax of the source
 		(cond
 		 ;; do nothing for an empty result
 		 ((null result))
+		 ;; illegal inline result or params
+		 (bad-inline-p
+		  (error "Inline error: %s cannot be used" bad-inline-p))
 		 ;; insert a list if preferred
 		 ((member "list" result-params)
 		  (insert
@@ -2208,44 +2253,59 @@ code ---- the results are extracted in the syntax of the source
 		 ((and (listp result) (not (funcall proper-list-p result)))
 		  (insert (format "%s\n" result)))
 		 ((member "file" result-params)
-		  (when inlinep (goto-char inlinep))
+		  (when inlinep
+		    (goto-char inlinep)
+		    (setq result) (org-macro-escape-arguments result))
 		  (insert result))
+		 ((and inlinep
+		       (not (member "raw" result-params)))
+		  (goto-char inlinep)
+		  (insert (org-macro-escape-arguments
+			   (org-babel-chomp result "\n"))))
 		 (t (goto-char beg) (insert result)))
 		(when (funcall proper-list-p result) (goto-char (org-table-end)))
 		(setq end (point-marker))
 		;; possibly wrap result
 		(cond
+		 (bad-inline-p) ;; do nothing
 		 ((assoc :wrap (nth 2 info))
 		  (let ((name (or (cdr (assoc :wrap (nth 2 info))) "RESULTS")))
 		    (funcall wrap (concat "#+BEGIN_" name)
-			     (concat "#+END_" (car (org-split-string name))))))
+			     (concat "#+END_" (car (org-split-string name)))
+			     nil nil (concat "{{{results(@@" name ":") "@@)}}}")))
 		 ((member "html" result-params)
-		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML"))
-		 ((member "latex" result-params)
-		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX"))
+		  (funcall wrap "#+BEGIN_HTML" "#+END_HTML" nil nil
+			   "{{{results(@@html:" "@@)}}}"))
+		 ((member "latex" result-params) 
+		  (funcall wrap "#+BEGIN_LaTeX" "#+END_LaTeX" nil nil
+			   "{{{results(@@latex:" "@@)}}}"))
 		 ((member "org" result-params)
 		  (goto-char beg) (if (org-at-table-p) (org-cycle))
-		  (if inlinep
-		      (funcall wrap "src_org{" "}" nil t)
-		      (funcall wrap "#+BEGIN_SRC org" "#+END_SRC")))
+		  (funcall wrap "#+BEGIN_SRC org" "#+END_SRC" nil nil
+			   "{{{results(src_org{" "})}}}"))
 		 ((member "code" result-params)
 		  (let ((lang (or lang "none")))
-		    (if inlinep
-			(funcall wrap (format "src_%s[%s]{" lang results-switches)
-				 "}" nil t)
-			(funcall wrap (format "#+BEGIN_SRC %s%s" lang results-switches)
-				 "#+END_SRC"))))
+		    (funcall wrap (format "#+BEGIN_SRC %s%s" lang results-switches)
+			     "#+END_SRC" nil nil
+			     (format "{{{results(src_%s[%s]{" lang results-switches)
+			     "})}}}")))
 		 ((member "raw" result-params)
 		  (goto-char beg) (if (org-at-table-p) (org-cycle)))
 		 ((or (member "drawer" result-params)
 		      ;; Stay backward compatible with <7.9.2
 		      (member "wrap" result-params))
 		  (goto-char beg) (if (org-at-table-p) (org-cycle))
-		  (funcall wrap ":RESULTS:" ":END:" 'no-escape))
+		  (funcall wrap ":RESULTS:" ":END:" 'no-escape nil
+			   "{{{results(" ")}}}"))
+		 ((and inlinep (member "file" result-params))
+		  (funcall wrap nil nil nil nil "{{{results(" ")}}}"))
 		 ((and (not (funcall proper-list-p result))
 		       (not (member "file" result-params)))
-		  (org-babel-examplify-region beg end results-switches)
-		  (setq end (point)))))
+		  (let ((org-babel-inline-result-wrap
+			 ;; Hard code {{{results(...)}}} on top of customization.
+			 (format "{{{results(%s)}}}" org-babel-inline-result-wrap)))
+		    (org-babel-examplify-region beg end results-switches)
+		    (setq end (point))))))
 	      ;; possibly indent the results to match the #+results line
 	      (when (and (not inlinep) (numberp indent) indent (> indent 0)
 			 ;; in this case `table-align' does the work for us
@@ -2273,6 +2333,24 @@ code ---- the results are extracted in the syntax of the source
 	   (if keep-keyword (1+ (match-end 0)) (1- (match-beginning 0)))
 	   (progn (forward-line 1) (org-babel-result-end))))))))
 
+(defun org-babel-remove-inline-result ()
+  "Remove the result of the current inline-src-block or babel call.
+The result must be wrapped in a `results' macro to be
+  removed. Extraneous leading whitespace is trimmed."
+  (let* ((el (org-element-context))
+	 (post-blank (org-element-property :post-blank el)))
+    (when (memq (org-element-type el) '(inline-src-block inline-babel-call))
+      (org-with-wide-buffer
+        (goto-char (org-element-property :end el))
+        (let  ((el (org-element-context)))
+	  (when (and (eq (org-element-type el) 'macro)
+		     (string= (org-element-property :key el) "results"))
+	    (delete-region ; And (only) extra leading whitespace.
+	     (- (org-element-property :begin el)
+		(- post-blank 1))
+	     (- (org-element-property :end el)
+		(org-element-property :post-blank el)))))))))
+
 (defun org-babel-remove-result-one-or-many (x)
   "Remove the result of the current source block.
 If called with a prefix argument, remove all result blocks
-- 
1.9.3 (Apple Git-50)


[-- Attachment #5: usage examples --]
[-- Type: TEXT/PLAIN, Size: 9714 bytes --]

Demonstrate inline-src block-behavior and the {{{results( )}}} macro.

The `demo' src block sets up an inline-src-block, calls it, then
exports the result. The output is as follows:

- inline-src-block :: inline-src-block with headers and content.
- export backend :: Which backend was used to render the result.
- result :: What the ~*.org~ buffer looks looks like after babel
     executes the inline-src-block. If an error stops execution, the
     phrase 'Stopped for Error' is shown after the inline src block.
- exported as :: Show the exported version (starting on the next
     line). If an error stops execution, the phrase 'Stopped for
     Error' is shown.

* :results replace (default) 


#+name: demo
#+BEGIN_SRC emacs-lisp :var str="replace" bkend="ascii" contents="42"
  (let ((cmd (format "src_emacs-lisp[:results %s]{%s}" str contents)))
    (concat "inline-src-block: " cmd "\nexport backend: " bkend 
            "\nresult: " (with-temp-buffer
                           (insert cmd)
                           (or (ignore-errors
                                 (org-babel-execute-buffer))
                               (progn
                                 (goto-char (point-max))
                                 (insert "Stopped for Error")))
                           (buffer-string))
            "\nexported as:\n"
            (or
             (ignore-errors
               (org-export-string-as cmd (intern bkend) t))
             "Stopped for Error")))
#+END_SRC

#+RESULTS: demo
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} {{{results(=42=)}}}
: exported as:
: `42'


#+CALL: demo("replace")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace]{42} {{{results(=42=)}}}
: exported as:
: `42'

* :results html under html backend

#+CALL: demo("html","html")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html]{42}
: export backend: html
: result: src_emacs-lisp[:results html]{42} {{{results(@@html:42@@)}}}
: exported as:
: <p>
: 42</p>

* :results html under latex backend

#+CALL: demo("html","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results html]{42}
: export backend: latex
: result: src_emacs-lisp[:results html]{42} {{{results(@@html:42@@)}}}
: exported as:

* :results latex under latex backend

#+CALL: demo("latex","latex")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results latex]{42}
: export backend: latex
: result: src_emacs-lisp[:results latex]{42} {{{results(@@latex:42@@)}}}
: exported as:
: 42

* :results replace :wrap ascii

#+CALL: demo("replace :wrap ascii","ascii")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace :wrap ascii]{42}
: export backend: ascii
: result: src_emacs-lisp[:results replace :wrap ascii]{42} {{{results(@@ascii:42@@)}}}
: exported as:
: 42

* :results raw

#+CALL: demo("raw")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results raw]{42}
: export backend: ascii
: result: src_emacs-lisp[:results raw]{42} 42
: exported as:
: 42

* :results drawer

Same as default.

#+CALL: demo("drawer")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results drawer]{42}
: export backend: ascii
: result: src_emacs-lisp[:results drawer]{42} {{{results(42)}}}
: exported as:
: 42

* :results org

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("org")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results org]{42}
: export backend: ascii
: result: src_emacs-lisp[:results org]{42} {{{results(src_org{42})}}}
: exported as:
: `42'

* :results code

Code is quoted like this: `42' under ascii backend.

#+CALL: demo("code")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{42}
: export backend: ascii
: result: src_emacs-lisp[:results code]{42} {{{results(src_emacs-lisp[]{42})}}}
: exported as:
: `42'

* :results list

Lists and tables should be avoided for inline-src-blocks, but for
completeness some are listed here.

#+CALL: demo("list")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results list]{42}
: export backend: ascii
: result: src_emacs-lisp[:results list]{42} Stopped for Error
: exported as:
: Stopped for Error

* :results table

#+CALL: demo("table")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results table]{42}
: export backend: ascii
: result: src_emacs-lisp[:results table]{42} Stopped for Error
: exported as:
: Stopped for Error

* :results replace, proper list as content

Proper lists become tables.

#+CALL: demo(contents="\'(42)")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results replace]{'(42) }
: export backend: ascii
: result: src_emacs-lisp[:results replace]{'(42) } Stopped for Error
: exported as:
: Stopped for Error

* :results code, contents as elisp

#+CALL: demo("code",contents="(quote (+ 1 2))")

#+RESULTS:
: inline-src-block: src_emacs-lisp[:results code]{(quote (+ 1 2) )}
: export backend: ascii
: result: src_emacs-lisp[:results code]{(quote (+ 1 2) )} {{{results(src_emacs-lisp[]{(+ 1 2)})}}}
: exported as:
: `(+ 1 2)'



* inline calls

The `demo' src block sets up an inline-babel-call, calls it, then
exports the result. The output is as described above.



#+name: square-code
#+begin_src org :export code :eval no
  ,#+name: square
  ,#+BEGIN_SRC emacs-lisp :var x=1 :exports none
  (* x x)
  ,#+end_src
#+end_src

#+name: demo_calls
#+BEGIN_SRC emacs-lisp :var str="replace" bkend="ascii" contents=3 :noweb yes
    (let ((cmd (format "call_square(%s)[:results %s] " contents str)))
      (concat "inline-babel-call: " cmd "\nexport backend: " bkend 
              "\nresult: " (with-temp-buffer
                             (insert cmd "
  <<square-code>>"
                                     )
                             (or (ignore-errors
                                   (org-babel-execute-buffer))
                                 (progn
                                   (goto-char (point-min))
                                   (goto-char (point-at-eol))
                                   (insert "Stopped for Error")))
                             (let (( bstr (buffer-string)))
                               (replace-regexp-in-string "\n[#]\\(.\\|\n\\)*" "" 
                               bstr)))
              "\nexported as:\n"
              (or
               (ignore-errors
                 (org-export-string-as
                  (concat "
  <<square-code>>"
                          "\n" cmd)
                  (intern bkend) t))
               "Stopped for Error")))

#+END_SRC

#+RESULTS: demo_calls
: inline-babel-call: call_square(3)[:results replace] 
: export backend: ascii
: result: call_square(3)[:results replace] {{{results(=9=)}}} 
: exported as:
: `9'


#+CALL: demo_calls("replace")

#+RESULTS:
: inline-babel-call: call_square(3)[:results replace] 
: export backend: ascii
: result: call_square(3)[:results replace] {{{results(=9=)}}} 
: exported as:
: `9'

#+CALL: demo_calls("html","html")

#+RESULTS:
: inline-babel-call: call_square(3)[:results html] 
: export backend: html
: result: call_square(3)[:results html] {{{results(@@html:9@@)}}} 
: exported as:
: <p>
: 9 </p>

#+CALL: demo_calls("html","latex")

#+RESULTS:
: inline-babel-call: call_square(3)[:results html] 
: export backend: latex
: result: call_square(3)[:results html] {{{results(@@html:9@@)}}} 
: exported as:
:  

#+CALL: demo_calls("latex","latex")

#+RESULTS:
: inline-babel-call: call_square(3)[:results latex] 
: export backend: latex
: result: call_square(3)[:results latex] {{{results(@@latex:9@@)}}} 
: exported as:
: 9 

#+CALL: demo_calls("raw")

#+RESULTS:
: inline-babel-call: call_square(3)[:results raw] 
: export backend: ascii
: result: call_square(3)[:results raw] 9 
: exported as:
: 9

#+CALL: demo_calls("drawer")

#+RESULTS:
: inline-babel-call: call_square(3)[:results drawer] 
: export backend: ascii
: result: call_square(3)[:results drawer] {{{results(9)}}} 
: exported as:
: 9

#+CALL: demo_calls("org")

#+RESULTS:
: inline-babel-call: call_square(3)[:results org] 
: export backend: ascii
: result: call_square(3)[:results org] {{{results(src_org{9})}}} 
: exported as:
: `9'

#+CALL: demo_calls("list")

#+RESULTS:
: inline-babel-call: call_square(3)[:results list] 
: export backend: ascii
: result: call_square(3)[:results list]  Stopped for Error
: exported as:
: Stopped for Error

#+CALL: demo_calls("code")

#+RESULTS:
: inline-babel-call: call_square(3)[:results code] 
: export backend: ascii
: result: call_square(3)[:results code] {{{results(src_emacs-lisp[]{9})}}} 
: exported as:
: `9'

#+CALL: demo_calls("table")

#+RESULTS:
: inline-babel-call: call_square(3)[:results table] 
: export backend: ascii
: result: call_square(3)[:results table]  Stopped for Error
: exported as:
: Stopped for Error

#+CALL: demo_calls("code",contents="(quote (+ 1 2))")

#+RESULTS:
: inline-babel-call: call_square((quote (+ 1 2) ))[:results code] 
: export backend: ascii
: result: call_square((quote (+ 1 2) ))[:results code] Stopped for Error
: exported as:
: Stopped for Error

#+CALL: demo_calls("replace :wrap ascii","ascii")

#+RESULTS:
: inline-babel-call: call_square(3)[:results replace :wrap ascii] 
: export backend: ascii
: result: call_square(3)[:results replace :wrap ascii] {{{results(@@ascii:9@@)}}} 
: exported as:
: 9

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> I attach 3 patches and a file of usage examples.

Thanks.

> +    (let* ((el (org-element-context))
> +	   (beg (org-element-property :begin el))
> +	   (type (org-element-type el)))
> +      (when (eq type 'inline-babel-call)
> +	(goto-char beg)))

Nitpick: this looks like a lot of bindings for a dubious readability
improvement. What about:

  (let ((datum (org-element-context)))
    (when (eq (org-element-type datum) 'inline-babel-call)
      (goto-char (org-element-property :begin datum))))

> +	     (bad-inline-p
> +	      (when inlinep
> +		(or
> +		 (and (member "table" result-params) "`:results table'")
> +		 (and (listp result) "list result")
> +		 (and (string-match-p "\n." result) "multiline result")

`string-match-p' => `org-string-match-p'

>  		(cond
>  		 ;; do nothing for an empty result
>  		 ((null result))
> +		 ;; illegal inline result or params

Capital and final dot.

> +		  (when inlinep
> +		    (goto-char inlinep)
> +		    (setq result) (org-macro-escape-arguments result))

  (setq result (org-macro-escape-arguments result))

> +		 (bad-inline-p) ;; do nothing

Single semicolon for end-of-line comments, and capital+final dot.

> +(defun org-babel-remove-inline-result ()
> +  "Remove the result of the current inline-src-block or babel call.
> +The result must be wrapped in a `results' macro to be
> +  removed. Extraneous leading whitespace is trimmed."
> +  (let* ((el (org-element-context))
> +	 (post-blank (org-element-property :post-blank el)))
> +    (when (memq (org-element-type el) '(inline-src-block inline-babel-call))
> +      (org-with-wide-buffer
> +        (goto-char (org-element-property :end el))
> +        (let  ((el (org-element-context)))

               ^^^
           spurious space

This looks good. I think you can push them into master once the minor
issues above are fixed and if all tests pass.


Regards,

-- 
Nicolas Goaziou

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

On Thu, 22 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> I attach 3 patches and a file of usage examples.
>
> Thanks.
>

[delete - numerous pointers to small issues]

>
> This looks good. I think you can push them into master once the minor
> issues above are fixed and if all tests pass.
>

I fixed the issues from Nicolas's last email.

All tests passed (modulo a few shell and fortran issues unique to my setup 
which also failed for master).

Then I did an update and `git merge master' and got a pile of errors due to

   commit fda70440f49292197d76ce4c2727dbf426bc65f3
   Author: Aaron Ecay <aaronecay@gmail.com>
   Date:   Thu Jan 22 00:59:04 2015 -0500

which explicitly tests for conformity to the old inline regime or
at least depends on it.

I can change the relevant test/lisp/*.el in the next week or so to fix
those.

I am not sure if I can push to the main repos (or just to worg), but have
emailed Jason to confirm. Hopefully, by the time I iron out the other 
issues I will be able to push.

So, in a bit this should be resolved.

Best,

Chuck

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Aaron Ecay]

Hi Chuck,

2015ko urtarrilak 24an, "Charles C. Berry"-ek idatzi zuen:
> All tests passed (modulo a few shell and fortran issues unique to my setup 
> which also failed for master).
> 
> Then I did an update and `git merge master' and got a pile of errors due to
> 
>    commit fda70440f49292197d76ce4c2727dbf426bc65f3
>    Author: Aaron Ecay <aaronecay@gmail.com>
>    Date:   Thu Jan 22 00:59:04 2015 -0500
> 
> which explicitly tests for conformity to the old inline regime or
> at least depends on it.

By “pile of errors” do you mean test failures or merge conflicts?
AFAICS the patches you sent to the list did not touch the test suite, so
there should not be merge conflicts.  But maybe you had a patch for the
tests that you didn’t send.  (If I somehow caused merge conflicts for
your patches, I would offer to help fix them.)

The test suite depends on the specific way in which inline results
are inserted, so it will need to be updated to take account of your
change.  The commit you referenced doesn’t fundamentally alter that
dependency, though it does remove what used to be a requirement that
‘org-babel-inline-results-wrap’ be set to its default value.

Thanks,

-- 
Aaron Ecay

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1461 bytes --]

On Sat, 24 Jan 2015, Aaron Ecay wrote:

> Hi Chuck,
>
> 2015ko urtarrilak 24an, "Charles C. Berry"-ek idatzi zuen:
>> All tests passed (modulo a few shell and fortran issues unique to my setup
>> which also failed for master).
>>
>> Then I did an update and `git merge master' and got a pile of errors due to
>>
>>    commit fda70440f49292197d76ce4c2727dbf426bc65f3
>>    Author: Aaron Ecay <aaronecay@gmail.com>
>>    Date:   Thu Jan 22 00:59:04 2015 -0500
>>
>> which explicitly tests for conformity to the old inline regime or
>> at least depends on it.
>
> By “pile of errors” do you mean test failures or merge conflicts?
> AFAICS the patches you sent to the list did not touch the test suite, so
> there should not be merge conflicts.  But maybe you had a patch for the
> tests that you didn’t send.  (If I somehow caused merge conflicts for
> your patches, I would offer to help fix them.)
>
> The test suite depends on the specific way in which inline results
> are inserted, so it will need to be updated to take account of your
> change.

`test failures' is what I meant - sorry for being vague.

No merge issues.

I will mostly have to edit in the `{{{results(' `)}}}' wrappers in the 
places where the expected results are specified or specify [:results ...] 
to make the result agree with the specification, I guess.

Thanks for your commit, BTW. I was feeling guilty about not having any 
tests, so my conscience is off the hook now.

Chuck

Re: New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

The changes have been pushed to master just now.

To recap, inline src blocks and babel calls will now wrap their output in 
a `results' macro following the src block or call, replacing any previous 
such macro.

`:results raw' prevents the wrapping from taking place.

If the RESULT is a list or table or has more than one line (after 
stripping  trailing newline) an error is thrown. Likewise `:results list' 
and `:results table' throw an error.

`:results latex' (or html) will wrap the RESULT in a latex (html) export 
snippet. `:wrap blah' will produce a 'blah' snippet.

All of this should be utterly transparent on export, but there is one 
change I call to your attention:

This block:

 	src_emacs-lisp[:results code]{`(+ 1 2)}

yields this result:

 	{{{results(src_emacs-lisp[]{(+ 1 2)})}}}

which will export as

 	`(+ 1 2)'

under the 'ascii backend. Formerly, the `(+ 1 2)' would be evaluated by 
babel. If that behavior is truly needed, it can be restored. But in our 
discussions till now nobody has raised the issue, so I guessed the change 
would cause no headaches.

Best,

Chuck

On Thu, 22 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> I attach 3 patches and a file of usage examples.
>
> Thanks.
>
>> +    (let* ((el (org-element-context))
>> +	   (beg (org-element-property :begin el))
>> +	   (type (org-element-type el)))
>> +      (when (eq type 'inline-babel-call)
>> +	(goto-char beg)))
>
> Nitpick: this looks like a lot of bindings for a dubious readability
> improvement. What about:
>
>  (let ((datum (org-element-context)))
>    (when (eq (org-element-type datum) 'inline-babel-call)
>      (goto-char (org-element-property :begin datum))))
>
>> +	     (bad-inline-p
>> +	      (when inlinep
>> +		(or
>> +		 (and (member "table" result-params) "`:results table'")
>> +		 (and (listp result) "list result")
>> +		 (and (string-match-p "\n." result) "multiline result")
>
> `string-match-p' => `org-string-match-p'
>
>>  		(cond
>>  		 ;; do nothing for an empty result
>>  		 ((null result))
>> +		 ;; illegal inline result or params
>
> Capital and final dot.
>
>> +		  (when inlinep
>> +		    (goto-char inlinep)
>> +		    (setq result) (org-macro-escape-arguments result))
>
>  (setq result (org-macro-escape-arguments result))
>
>> +		 (bad-inline-p) ;; do nothing
>
> Single semicolon for end-of-line comments, and capital+final dot.
>
>> +(defun org-babel-remove-inline-result ()
>> +  "Remove the result of the current inline-src-block or babel call.
>> +The result must be wrapped in a `results' macro to be
>> +  removed. Extraneous leading whitespace is trimmed."
>> +  (let* ((el (org-element-context))
>> +	 (post-blank (org-element-property :post-blank el)))
>> +    (when (memq (org-element-type el) '(inline-src-block inline-babel-call))
>> +      (org-with-wide-buffer
>> +        (goto-char (org-element-property :end el))
>> +        (let  ((el (org-element-context)))
>
>               ^^^
>           spurious space
>
> This looks good. I think you can push them into master once the minor
> issues above are fixed and if all tests pass.
>
>
> Regards,
>
> -- 
> Nicolas Goaziou
>

Charles C. Berry                 Dept of Family Medicine & Public Health
cberry at ucsd edu               UC San Diego / La Jolla, CA 92093-0901
http://famprevmed.ucsd.edu/faculty/cberry/