* [PATCH] inline src block results can be removed @ 2014-11-12 0:49 Charles C. Berry 2014-11-12 1:10 ` Andreas Leha 2014-11-12 19:34 ` Aaron Ecay 0 siblings, 2 replies; 32+ messages in thread From: Charles C. Berry @ 2014-11-12 0:49 UTC (permalink / raw) To: emacs-orgmode; +Cc: mcg, Andreas Leha, Ista Zahn, Nicolas Goaziou [-- 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) ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-12 0:49 [PATCH] inline src block results can be removed Charles C. Berry @ 2014-11-12 1:10 ` Andreas Leha 2014-11-12 6:58 ` Charles C. Berry 2014-11-12 19:34 ` Aaron Ecay 1 sibling, 1 reply; 32+ messages in thread From: Andreas Leha @ 2014-11-12 1:10 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-12 1:10 ` Andreas Leha @ 2014-11-12 6:58 ` Charles C. Berry 0 siblings, 0 replies; 32+ messages in thread From: Charles C. Berry @ 2014-11-12 6:58 UTC (permalink / raw) To: Andreas Leha; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-12 0:49 [PATCH] inline src block results can be removed Charles C. Berry 2014-11-12 1:10 ` Andreas Leha @ 2014-11-12 19:34 ` Aaron Ecay 2014-11-12 23:47 ` Charles C. Berry 1 sibling, 1 reply; 32+ messages in thread From: Aaron Ecay @ 2014-11-12 19:34 UTC (permalink / raw) To: Charles C. Berry, emacs-orgmode Cc: mcg, Andreas Leha, Ista Zahn, Nicolas Goaziou 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-12 19:34 ` Aaron Ecay @ 2014-11-12 23:47 ` Charles C. Berry 2014-11-13 17:48 ` Nicolas Goaziou 0 siblings, 1 reply; 32+ messages in thread From: Charles C. Berry @ 2014-11-12 23:47 UTC (permalink / raw) To: Aaron Ecay; +Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn, Nicolas Goaziou [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-12 23:47 ` Charles C. Berry @ 2014-11-13 17:48 ` Nicolas Goaziou 2014-11-13 19:06 ` Andreas Leha 2014-11-14 17:43 ` Charles C. Berry 0 siblings, 2 replies; 32+ messages in thread From: Nicolas Goaziou @ 2014-11-13 17:48 UTC (permalink / raw) To: Charles C. Berry; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-13 17:48 ` Nicolas Goaziou @ 2014-11-13 19:06 ` Andreas Leha 2014-11-14 17:43 ` Charles C. Berry 1 sibling, 0 replies; 32+ messages in thread From: Andreas Leha @ 2014-11-13 19:06 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-13 17:48 ` Nicolas Goaziou 2014-11-13 19:06 ` Andreas Leha @ 2014-11-14 17:43 ` Charles C. Berry 2014-11-14 20:39 ` Nicolas Goaziou 1 sibling, 1 reply; 32+ messages in thread From: Charles C. Berry @ 2014-11-14 17:43 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg [-- 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)}}} ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-14 17:43 ` Charles C. Berry @ 2014-11-14 20:39 ` Nicolas Goaziou 2014-11-14 23:04 ` Aaron Ecay 2014-11-15 20:22 ` Charles C. Berry 0 siblings, 2 replies; 32+ messages in thread From: Nicolas Goaziou @ 2014-11-14 20:39 UTC (permalink / raw) To: Charles C. Berry; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg "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, ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-14 20:39 ` Nicolas Goaziou @ 2014-11-14 23:04 ` Aaron Ecay 2014-11-16 0:10 ` Nicolas Goaziou 2014-11-15 20:22 ` Charles C. Berry 1 sibling, 1 reply; 32+ messages in thread From: Aaron Ecay @ 2014-11-14 23:04 UTC (permalink / raw) To: Nicolas Goaziou, Charles C. Berry Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-14 23:04 ` Aaron Ecay @ 2014-11-16 0:10 ` Nicolas Goaziou 0 siblings, 0 replies; 32+ messages in thread From: Nicolas Goaziou @ 2014-11-16 0:10 UTC (permalink / raw) To: Charles C. Berry; +Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-14 20:39 ` Nicolas Goaziou 2014-11-14 23:04 ` Aaron Ecay @ 2014-11-15 20:22 ` Charles C. Berry 2014-11-16 23:23 ` Nicolas Goaziou 1 sibling, 1 reply; 32+ messages in thread From: Charles C. Berry @ 2014-11-15 20:22 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-15 20:22 ` Charles C. Berry @ 2014-11-16 23:23 ` Nicolas Goaziou 2014-11-24 9:48 ` Daniele Pizzolli 2015-01-13 0:48 ` New patches WAS " Charles C. Berry 0 siblings, 2 replies; 32+ messages in thread From: Nicolas Goaziou @ 2014-11-16 23:23 UTC (permalink / raw) To: Charles C. Berry; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg "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, ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-16 23:23 ` Nicolas Goaziou @ 2014-11-24 9:48 ` Daniele Pizzolli 2014-11-24 10:18 ` Andreas Leha 2015-01-13 0:48 ` New patches WAS " Charles C. Berry 1 sibling, 1 reply; 32+ messages in thread From: Daniele Pizzolli @ 2014-11-24 9:48 UTC (permalink / raw) To: Charles C. Berry, Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] inline src block results can be removed 2014-11-24 9:48 ` Daniele Pizzolli @ 2014-11-24 10:18 ` Andreas Leha 0 siblings, 0 replies; 32+ messages in thread From: Andreas Leha @ 2014-11-24 10:18 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* New patches WAS Re: [PATCH] inline src block results can be removed 2014-11-16 23:23 ` Nicolas Goaziou 2014-11-24 9:48 ` Daniele Pizzolli @ 2015-01-13 0:48 ` Charles C. Berry 2015-01-16 22:41 ` Nicolas Goaziou 2015-01-17 3:22 ` Aaron Ecay 1 sibling, 2 replies; 32+ messages in thread From: Charles C. Berry @ 2015-01-13 0:48 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg [-- 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) } ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-13 0:48 ` New patches WAS " Charles C. Berry @ 2015-01-16 22:41 ` Nicolas Goaziou 2015-01-19 3:22 ` Charles C. Berry 2015-01-17 3:22 ` Aaron Ecay 1 sibling, 1 reply; 32+ messages in thread From: Nicolas Goaziou @ 2015-01-16 22:41 UTC (permalink / raw) To: Charles C. Berry; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg "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, ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-16 22:41 ` Nicolas Goaziou @ 2015-01-19 3:22 ` Charles C. Berry 2015-01-19 17:53 ` Nicolas Goaziou 0 siblings, 1 reply; 32+ messages in thread From: Charles C. Berry @ 2015-01-19 3:22 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg [-- 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) } ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-19 3:22 ` Charles C. Berry @ 2015-01-19 17:53 ` Nicolas Goaziou 2015-01-19 19:31 ` Charles C. Berry 0 siblings, 1 reply; 32+ messages in thread From: Nicolas Goaziou @ 2015-01-19 17:53 UTC (permalink / raw) To: Charles C. Berry; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg "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, ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-19 17:53 ` Nicolas Goaziou @ 2015-01-19 19:31 ` Charles C. Berry 2015-01-20 23:30 ` Nicolas Goaziou 0 siblings, 1 reply; 32+ messages in thread From: Charles C. Berry @ 2015-01-19 19:31 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-19 19:31 ` Charles C. Berry @ 2015-01-20 23:30 ` Nicolas Goaziou 2015-01-22 3:07 ` Charles C. Berry 0 siblings, 1 reply; 32+ messages in thread From: Nicolas Goaziou @ 2015-01-20 23:30 UTC (permalink / raw) To: Charles C. Berry; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg "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, ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-20 23:30 ` Nicolas Goaziou @ 2015-01-22 3:07 ` Charles C. Berry 2015-01-22 23:08 ` Nicolas Goaziou 0 siblings, 1 reply; 32+ messages in thread From: Charles C. Berry @ 2015-01-22 3:07 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg [-- 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 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-22 3:07 ` Charles C. Berry @ 2015-01-22 23:08 ` Nicolas Goaziou 2015-01-24 22:47 ` Charles C. Berry 2015-01-29 20:31 ` Charles C. Berry 0 siblings, 2 replies; 32+ messages in thread From: Nicolas Goaziou @ 2015-01-22 23:08 UTC (permalink / raw) To: Charles C. Berry; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg "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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-22 23:08 ` Nicolas Goaziou @ 2015-01-24 22:47 ` Charles C. Berry 2015-01-25 1:14 ` Aaron Ecay 2015-01-29 20:31 ` Charles C. Berry 1 sibling, 1 reply; 32+ messages in thread From: Charles C. Berry @ 2015-01-24 22:47 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-24 22:47 ` Charles C. Berry @ 2015-01-25 1:14 ` Aaron Ecay 2015-01-25 5:01 ` Charles C. Berry 0 siblings, 1 reply; 32+ messages in thread From: Aaron Ecay @ 2015-01-25 1:14 UTC (permalink / raw) To: Charles C. Berry; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-25 1:14 ` Aaron Ecay @ 2015-01-25 5:01 ` Charles C. Berry 0 siblings, 0 replies; 32+ messages in thread From: Charles C. Berry @ 2015-01-25 5:01 UTC (permalink / raw) To: Aaron Ecay; +Cc: emacs-orgmode [-- 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-22 23:08 ` Nicolas Goaziou 2015-01-24 22:47 ` Charles C. Berry @ 2015-01-29 20:31 ` Charles C. Berry 1 sibling, 0 replies; 32+ messages in thread From: Charles C. Berry @ 2015-01-29 20:31 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Aaron Ecay, Andreas Leha, emacs-orgmode, Ista Zahn, mcg 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/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-13 0:48 ` New patches WAS " Charles C. Berry 2015-01-16 22:41 ` Nicolas Goaziou @ 2015-01-17 3:22 ` Aaron Ecay 2015-01-17 22:20 ` Nicolas Goaziou 1 sibling, 1 reply; 32+ messages in thread From: Aaron Ecay @ 2015-01-17 3:22 UTC (permalink / raw) To: Charles C. Berry, Nicolas Goaziou Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-17 3:22 ` Aaron Ecay @ 2015-01-17 22:20 ` Nicolas Goaziou 2015-01-18 19:13 ` Aaron Ecay 0 siblings, 1 reply; 32+ messages in thread From: Nicolas Goaziou @ 2015-01-17 22:20 UTC (permalink / raw) To: Charles C. Berry; +Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-17 22:20 ` Nicolas Goaziou @ 2015-01-18 19:13 ` Aaron Ecay 2015-01-18 22:34 ` Nicolas Goaziou 0 siblings, 1 reply; 32+ messages in thread From: Aaron Ecay @ 2015-01-18 19:13 UTC (permalink / raw) To: Nicolas Goaziou, Charles C. Berry Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-18 19:13 ` Aaron Ecay @ 2015-01-18 22:34 ` Nicolas Goaziou 2015-01-18 22:55 ` Aaron Ecay 0 siblings, 1 reply; 32+ messages in thread From: Nicolas Goaziou @ 2015-01-18 22:34 UTC (permalink / raw) To: Charles C. Berry; +Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn 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, ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New patches WAS Re: [PATCH] inline src block results can be removed 2015-01-18 22:34 ` Nicolas Goaziou @ 2015-01-18 22:55 ` Aaron Ecay 0 siblings, 0 replies; 32+ messages in thread From: Aaron Ecay @ 2015-01-18 22:55 UTC (permalink / raw) To: Nicolas Goaziou, Charles C. Berry Cc: mcg, Andreas Leha, emacs-orgmode, Ista Zahn 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2015-01-29 20:31 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-12 0:49 [PATCH] inline src block results can be removed Charles C. Berry 2014-11-12 1:10 ` Andreas Leha 2014-11-12 6:58 ` Charles C. Berry 2014-11-12 19:34 ` Aaron Ecay 2014-11-12 23:47 ` Charles C. Berry 2014-11-13 17:48 ` Nicolas Goaziou 2014-11-13 19:06 ` Andreas Leha 2014-11-14 17:43 ` Charles C. Berry 2014-11-14 20:39 ` Nicolas Goaziou 2014-11-14 23:04 ` Aaron Ecay 2014-11-16 0:10 ` Nicolas Goaziou 2014-11-15 20:22 ` Charles C. Berry 2014-11-16 23:23 ` Nicolas Goaziou 2014-11-24 9:48 ` Daniele Pizzolli 2014-11-24 10:18 ` Andreas Leha 2015-01-13 0:48 ` New patches WAS " Charles C. Berry 2015-01-16 22:41 ` Nicolas Goaziou 2015-01-19 3:22 ` Charles C. Berry 2015-01-19 17:53 ` Nicolas Goaziou 2015-01-19 19:31 ` Charles C. Berry 2015-01-20 23:30 ` Nicolas Goaziou 2015-01-22 3:07 ` Charles C. Berry 2015-01-22 23:08 ` Nicolas Goaziou 2015-01-24 22:47 ` Charles C. Berry 2015-01-25 1:14 ` Aaron Ecay 2015-01-25 5:01 ` Charles C. Berry 2015-01-29 20:31 ` Charles C. Berry 2015-01-17 3:22 ` Aaron Ecay 2015-01-17 22:20 ` Nicolas Goaziou 2015-01-18 19:13 ` Aaron Ecay 2015-01-18 22:34 ` Nicolas Goaziou 2015-01-18 22:55 ` Aaron Ecay
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).