[BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[Daniele Pizzolli]

Hello,

my attempt to use org-mode for both interactive presentation and final
report was unsuccessful due to a series of bugs and nuisances.
Fortunately I can use the result of tangle.  Will report the issues
encountered to the list in the next few days.

Here is a minor one.

The following code, taken from [[info:org#Languages]] works if run after
manually selecting it and running with M-x eval-region.  But with M-x
org-babel-execute-src-block it triggers an error.  The *Messages* buffer
shows:

#+BEGIN_EXAMPLE
executing Emacs-Lisp code block...
orgtbl-to-orgtbl: Wrong type argument: listp, t
#+END_EXAMPLE


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

#+BEGIN_SRC emacs-lisp
(org-version nil t)
#+END_SRC

#+RESULTS:
: Org-mode version 8.3beta (release_8.3beta-860-ge4da74 @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/)

Best,
Daniele

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[John Kitchin]

I am pretty sure this is a long-standing "feature".

Try this:
#+BEGIN_SRC emacs-lisp :results raw
(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . nil)
  (R . t)))
#+END_SRC

I have never been able to use a babel block  that outputs a list of cons
cells without explicitly setting results to raw or code. The problem
here is your code evaluates to ((emacs-lisp) (R . t)), and the t somehow
gets interpreted like it should be a list, which it is not. So, it
cannot be made into a table for output, and you get your error.

Changing the header just bypasses this function and outputs the results
more directly.

Daniele Pizzolli writes:

> Hello,
>
> my attempt to use org-mode for both interactive presentation and final
> report was unsuccessful due to a series of bugs and nuisances.
> Fortunately I can use the result of tangle.  Will report the issues
> encountered to the list in the next few days.
>
> Here is a minor one.
>
> The following code, taken from [[info:org#Languages]] works if run after
> manually selecting it and running with M-x eval-region.  But with M-x
> org-babel-execute-src-block it triggers an error.  The *Messages* buffer
> shows:
>
> #+BEGIN_EXAMPLE
> executing Emacs-Lisp code block...
> orgtbl-to-orgtbl: Wrong type argument: listp, t
> #+END_EXAMPLE
>
>
> #+BEGIN_SRC emacs-lisp
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((emacs-lisp . nil)
> (R . t)))
> #+END_SRC
>
> #+BEGIN_SRC emacs-lisp
> (org-version nil t)
> #+END_SRC
>
> #+RESULTS:
> : Org-mode version 8.3beta (release_8.3beta-860-ge4da74 @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/)
>
> Best,
> Daniele

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[Daniele Pizzolli]

John Kitchin writes:

> I am pretty sure this is a long-standing "feature".
>
> Try this:
> #+BEGIN_SRC emacs-lisp :results raw
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((emacs-lisp . nil)
>   (R . t)))
> #+END_SRC
>
> I have never been able to use a babel block  that outputs a list of cons
> cells without explicitly setting results to raw or code. The problem
> here is your code evaluates to ((emacs-lisp) (R . t)), and the t somehow
> gets interpreted like it should be a list, which it is not. So, it
> cannot be made into a table for output, and you get your error.
>
> Changing the header just bypasses this function and outputs the results
> more directly.

Hello John,

thanks for the explanation.

Unfortunately my lisp knowledge is too limited to understand you.  As a
naive org-mode user, if possible I do not want to be exposed to org
internals error, especially the confusing ones, where the custom code
works fine.  Maybe we can get a warning instead of an error?

It is not a really big issue, a newcomer can be confused, if not scared,
having an error on the fist babel usage.

Best,
Daniele

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[John Kitchin]

>
> thanks for the explanation.
>
> Unfortunately my lisp knowledge is too limited to understand you.  As a
> naive org-mode user, if possible I do not want to be exposed to org
> internals error, especially the confusing ones, where the custom code
> works fine.  Maybe we can get a warning instead of an error?
>
> It is not a really big issue, a newcomer can be confused, if not scared,
> having an error on the fist babel usage.

I agree. Even for experienced people, this is pretty annoying. Something
as simple as


#+BEGIN_SRC emacs-lisp
'((1 . nil) (2 . 3))
#+END_SRC

fails with a cryptic error. While this works fine. I would vote for a
fall-back to code or even a plain string in this case.

#+BEGIN_SRC emacs-lisp :results code
'((1 . nil) (2 . 3))
#+END_SRC

#+RESULTS:
#+BEGIN_SRC emacs-lisp
((1)
 (2 . 3))
#+END_SRC



>
> Best,
> Daniele

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[Nicolas Goaziou]

Hello,

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> I agree. Even for experienced people, this is pretty annoying. Something
> as simple as
>
>
> #+BEGIN_SRC emacs-lisp
> '((1 . nil) (2 . 3))
> #+END_SRC
>
> fails with a cryptic error. While this works fine. I would vote for a
> fall-back to code or even a plain string in this case.

Indeed. This should be fixed in
ad7b7efcdc2e0803cbf0257bb2588c8e8e1cac29.

If fall-backs to a plain string.

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[John Kitchin]

Fabulous! Thanks!

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> I agree. Even for experienced people, this is pretty annoying. Something
>> as simple as
>>
>>
>> #+BEGIN_SRC emacs-lisp
>> '((1 . nil) (2 . 3))
>> #+END_SRC
>>
>> fails with a cryptic error. While this works fine. I would vote for a
>> fall-back to code or even a plain string in this case.
>
> Indeed. This should be fixed in
> ad7b7efcdc2e0803cbf0257bb2588c8e8e1cac29.
>
> If fall-backs to a plain string.
>
> Thank you.
>
>
> Regards,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[Nicolas Goaziou]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> Fabulous! Thanks!

BTW,

  #+BEGIN_SRC emacs-lisp
    '((a (b)))
  #+END_SRC

  #+RESULTS: foo
  | a | (b) |

Shouldn't we also return lists deeper than 2 levels as strings? Does it
even make sense to try formatting them into a table?

Regards,

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[John Kitchin]

I don't have a strong opinion on this. My sense is if you get a table it
is fine, if not, you should get a string. Most important to me is no
error. Of second importance is usability of the result.

If I add this after the block, it works as expected for me, so the
current behavior seems ok to me.

#+BEGIN_SRC emacs-lisp :var d=foo :results code
d
#+END_SRC

I am not actually sure if a string is usable, without a read statement
for emacs-lisp.

Nicolas Goaziou writes:

> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> Fabulous! Thanks!
>
> BTW,
>
>   #+BEGIN_SRC emacs-lisp
>     '((a (b)))
>   #+END_SRC
>
>   #+RESULTS: foo
>   | a | (b) |
>
> Shouldn't we also return lists deeper than 2 levels as strings? Does it
> even make sense to try formatting them into a table?
>
> Regards,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

[PATCH] was Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[Charles C. Berry]

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

On Tue, 24 Feb 2015, Nicolas Goaziou wrote:

> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
>> Fabulous! Thanks!
>
> BTW,
>
>  #+BEGIN_SRC emacs-lisp
>    '((a (b)))
>  #+END_SRC
>
>  #+RESULTS: foo
>  | a | (b) |
>
> Shouldn't we also return lists deeper than 2 levels as strings? Does it
> even make sense to try formatting them into a table?
>

My vote is no - it doesn't make sense. Let the user pick `:results list' 
or `:results pp' after it returns a string.

BTW, the string produced when a list cannot be rendered as a table ought 
to be removable.

The patch makes such strings removable. i.e.

#+BEGIN_SRC emacs-lisp
org-babel-load-languages
#+END_SRC

will have the ": " prefix or #+begin/end_example delimiters to allow later 
removal like this:

#+RESULTS:
: ((R . t) (latex . t) ... (sql) ...


HTH,

Chuck

[-- Attachment #2: make stringified lists removable --]
[-- Type: TEXT/PLAIN, Size: 1243 bytes --]

From b1179a79c6d72cc0beab6e7fd9774f49ea1bbbae Mon Sep 17 00:00:00 2001
From: Charles Berry <ccberry@ucsd.edu>
Date: Tue, 24 Feb 2015 15:12:53 -0800
Subject: [PATCH] ob-core.el: examplify list made into strings

* ob-core.el (org-babel-insert-result): When a list cannot be rendered
  as a table and is turned into a string make it removable if
  `:results replace' (the default) or `:results table' was specified.
---
 lisp/ob-core.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index f2062ef..4be10c1 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2299,7 +2299,10 @@ INFO may provide the values of these header arguments (in the
 			   "{{{results(" ")}}}"))
 		 ((and inlinep (member "file" result-params))
 		  (funcall wrap nil nil nil nil "{{{results(" ")}}}"))
-		 ((and (not (funcall proper-list-p result))
+		 ((and (not (and (funcall proper-list-p result)
+			    (org-every (lambda (e)
+					 (or (atom e) (funcall proper-list-p e)))
+				       result)))
 		       (not (member "file" result-params)))
 		  (let ((org-babel-inline-result-wrap
 			 ;; Hard code {{{results(...)}}} on top of customization.
-- 
1.9.3 (Apple Git-50)

Re: [PATCH] was Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[Nicolas Goaziou]

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

> BTW, the string produced when a list cannot be rendered as a table ought 
> to be removable.
>
> The patch makes such strings removable. i.e.
>
> #+BEGIN_SRC emacs-lisp
> org-babel-load-languages
> #+END_SRC
>
> will have the ": " prefix or #+begin/end_example delimiters to allow later 
> removal like this:
>
> #+RESULTS:
> : ((R . t) (latex . t) ... (sql) ...

Indeed. I applied a similar patch in
1493151b3fa37496dda12ecbcfc94501ceeafd81. Thank you.


Regards,

Re: [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t

[Daniele Pizzolli]

Nicolas Goaziou writes:

> Hello,

[]

> Indeed. This should be fixed in
> ad7b7efcdc2e0803cbf0257bb2588c8e8e1cac29.
>
> If fall-backs to a plain string.
>
> Thank you.

Thanks to you for taking care so quickly!

Best,
Daniele