odd behavior for begin_src org :results

odd behavior for begin_src org :results

[Greg Minshall]

Org-mode version 8.0.1 (release_8.0.1-42-g267cbe @ /Users/minshall/usr/share/emacs/site-lisp/org/)

hi.  the following produces #+RESULTS:
----
#+begin_src org :results replace
hello
#+end_src
----
but, repeated evaluations seem to grow the list of results.  e.g., after
four evaluations:
----
#+RESULTS:
hello
hello
hello
hello
----

the following does not produce #+RESULTS at all:
----
#+begin_src org
hello
#+end_src
----

is this intended behavior?  the code thinks so; ob-org.el has:
----
(defvar org-babel-default-header-args:org
  '((:results . "raw silent") (:exports . "code"))
  "Default arguments for evaluating a org source block.")
----
otoh, the manual thinks ":results replace" should be the default:
----
   * 'replace' The default value.  Any existing results will be removed,
     and the new results will be inserted into the Org mode buffer in
     their place.  E.g., ':results output replace'.
----

cheers, Greg

Re: odd behavior for begin_src org :results

[Eric Schulte]

Greg Minshall <minshall@umich.edu> writes:

> Org-mode version 8.0.1 (release_8.0.1-42-g267cbe @ /Users/minshall/usr/share/emacs/site-lisp/org/)
>
> hi.  the following produces #+RESULTS:
> ----
> #+begin_src org :results replace
> hello
> #+end_src
> ----
> but, repeated evaluations seem to grow the list of results.  e.g., after
> four evaluations:
> ----
> #+RESULTS:
> hello
> hello
> hello
> hello
> ----
>

Yes, this is the behavior of raw results.

>
> the following does not produce #+RESULTS at all:
> ----
> #+begin_src org
> hello
> #+end_src
> ----
>
> is this intended behavior?

This is the intended behavior for Org-mode blocks, it is not the
intended behavior in general.

> the code thinks so; ob-org.el has:
> ----
> (defvar org-babel-default-header-args:org
>   '((:results . "raw silent") (:exports . "code"))
>   "Default arguments for evaluating a org source block.")
> ----
> otoh, the manual thinks ":results replace" should be the default:
> ----
>    * 'replace' The default value.  Any existing results will be removed,
>      and the new results will be inserted into the Org mode buffer in
>      their place.  E.g., ':results output replace'.
> ----
>

In this case the defaults for org-mode are different from the general
cross-language defaults.

As I recall, at the time that the defaults were set for Org-mode code
blocks, we did not have options like drawers to allow replaceable raw
results.  Perhaps the default header arguments for Org-mode should be
updated.

Best,

>
> cheers, Greg
>

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

Re: odd behavior for begin_src org :results

[Greg Minshall]

Eric,

thanks for the answer.  another "#+begin_src org" question.  it appears
that only *string* values are allowed for any :var that are defined
(i.e., ':var bar="foo"', and *not* ':var bar=3').  since i'm not 100%
sure of the semantics, maybe this is desired.

if one *should* be allowed to pass in, e.g., tables, numbers, etc., then
maybe org-babel-expand-body:org in ob-org.el wants to change from the
current
----
(defun org-babel-expand-body:org (body params)
  (dolist (var (mapcar #'cdr (org-babel-get-header params :var)))
    (setq body (replace-regexp-in-string
		(regexp-quote (format "$%s" (car var)))  (cdr var) body
		nil 'literal)))
  body)
----
to something like this
----
  (defun org-babel-expand-body:org (body params)
    (dolist (var (mapcar #'cdr (org-babel-get-header params :var)))
      (setq body (replace-regexp-in-string
                  (regexp-quote (format "$%s" (car var)))  
                  (if (stringp (cdr var))
                      (cdr var)
                    (format "%s" (prin1 (cdr var))))
                  body nil 'literal)))
    body)
----
(as otherwise replace-regexp-in-string notices that (cdr var) is *not* a
string, and attempts to execute it.)

maybe^2 it would make even more sense to use the "#+begin_src
emacs-lisp" equivalent routine from ob-emacs-lisp.el as a template?
----
(defun org-babel-expand-body:emacs-lisp (body params)
  "Expand BODY according to PARAMS, return the expanded body."
  (let* ((vars (mapcar #'cdr (org-babel-get-header params :var)))
         (result-params (cdr (assoc :result-params params)))
         (print-level nil) (print-length nil)
         (body (if (> (length vars) 0)
		   (concat "(let ("
			   (mapconcat
			    (lambda (var)
			      (format "%S" (print `(,(car var) ',(cdr var)))))
			    vars "\n      ")
			   ")\n" body "\n)")
		 (concat body "\n"))))
    (if (or (member "code" result-params)
	    (member "pp" result-params))
	(concat "(pp " body ")") body)))
----
(my elisp isn't strong enough to evaluate this.)

cheers, Greg

Re: odd behavior for begin_src org :results

[Sebastien Vauban]

Hello Greg,

Greg Minshall wrote:
> It appears that only *string* values are allowed for any :var that are
> defined (i.e., ':var bar="foo"', and *not* ':var bar=3').

Confirmed. The following does not work.

#+begin_src org :results drawer replace :var you=2
Hello $you
#+end_src

> since i'm not 100% sure of the semantics, maybe this is desired.

I dunno either. Clearly, an error should not happen. OTOH, there is no concept
of Org variable, so every variable here comes down to be implemented as a
simple string replacement, hence the need for strings only, maybe.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: odd behavior for begin_src org :results

[Eric Schulte]

"Sebastien Vauban" <sva-news@mygooglest.com> writes:

> Hello Greg,
>
> Greg Minshall wrote:
>> It appears that only *string* values are allowed for any :var that are
>> defined (i.e., ':var bar="foo"', and *not* ':var bar=3').
>
> Confirmed. The following does not work.
>
> #+begin_src org :results drawer replace :var you=2
> Hello $you
> #+end_src
>
>> since i'm not 100% sure of the semantics, maybe this is desired.
>
> I dunno either. Clearly, an error should not happen. OTOH, there is no concept
> of Org variable, so every variable here comes down to be implemented as a
> simple string replacement, hence the need for strings only, maybe.
>

I've applied a simple fix which will allow any type of object to be
inserted into an Org-mode code block.  Although there is a great deal of
potential for more sophisticated behavior here, hopefully this simple
solution will suffice.

>
> Best regards,
>   Seb

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