[Babel] Lisp error: (wrong-type-argument listp hline)

[Babel] Lisp error: (wrong-type-argument listp hline)

[Sebastien Vauban]

Hello Eric,

This ECM does generate an error, when run with ":hlines yes".

#+name: table
| Key | Value |
|-----+-------|
| ABJ |     1 |
| DEK |     2 |

As you can see, there is one header and one horizontal line in the input
table.

* Set :hlines to "no"

Adding `:hlines no' strips the horizontal line, but does keep the header.

  #+begin_src emacs-lisp :var data=table :results output :hlines no
  (mapc (lambda (item) (princ (format "UPDATE dim SET val=%s WHERE code='%s'\n"
                                      (nth 1 item) (nth 0 item))))
   data)
  #+end_src

  #+results:
  #+begin_example
  UPDATE dim SET val=Value WHERE code = 'Key'              <<< LINE NOT WANTED
  UPDATE dim SET val=1 WHERE code = 'ABJ'
  UPDATE dim SET val=2 WHERE code = 'DEK'
  #+end_example

* Set :hlines to "yes"

`:hlines yes' should leave the horizontal line, but generates an error.

  #+begin_src emacs-lisp :var data=table :results output :hlines yes
  (mapc (lambda (item) (princ (format "UPDATE dim SET val=%s WHERE code='%s'\n"
                                      (nth 1 item) (nth 0 item))))
   data)
  #+end_src

--8<---------------cut here---------------start------------->8---
  Debugger entered--Lisp error: (wrong-type-argument listp hline)
    nth(1 hline)
    (format "UPDATE dim SET val=%s WHERE code='%s'\n" (nth 1 item) (nth 0 item))
    (princ (format "UPDATE dim SET val=%s WHERE code='%s'\n" (nth 1 item) (nth 0 item)))
    (lambda (item) (princ (format "UPDATE dim SET val=%s WHERE code='%s'\n" (nth 1 item) (nth 0 item))))(hline)
    mapc((lambda (item) (princ (format "UPDATE dim SET val=%s WHERE code='%s'\n" (nth 1 item) (nth 0 item)))) (("Key" "Value") hline ("ABJ" 1) ("DEK" 2)))
    ...
    call-interactively(org-self-insert-command nil nil)
--8<---------------cut here---------------end--------------->8---

* Ignore the table header

Finally, how am I then supposed to *ignore the header line*?  By adding

  #+begin_src emacs-lisp
  (setq table (cdr table))
  #+end_src

?

Do I have to do that explicitly in my code block, or is there an option for
telling that to Babel?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [Babel] Lisp error: (wrong-type-argument listp hline)

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

Hi Seb,

I think you're confused by headers which are re-added by the colnames
machinery.  See the following which returns scalar output avoiding any
colnames post-processing.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: hlines.org --]
[-- Type: text/x-org, Size: 353 bytes --]

#+Property: results scalar

#+name: table
| Key | Value |
|-----+-------|
| ABJ |     1 |
| DEK |     2 |

#+begin_src emacs-lisp :var data=table :hlines no
  data
#+end_src

#+RESULTS:
: (("Key" "Value") ("ABJ" 1) ("DEK" 2))

#+begin_src emacs-lisp :var data=table :hlines yes
  data
#+end_src

#+RESULTS:
: (("Key" "Value") hline ("ABJ" 1) ("DEK" 2))

[-- Attachment #3: Type: text/plain, Size: 1054 bytes --]


> * Set :hlines to "yes"
>
> `:hlines yes' should leave the horizontal line, but generates an error.
>
>   #+begin_src emacs-lisp :var data=table :results output :hlines yes
>   (mapc (lambda (item) (princ (format "UPDATE dim SET val=%s WHERE code='%s'\n"
>                                       (nth 1 item) (nth 0 item))))
>    data)
>   #+end_src

This is not a babel error, this is an error in your code block body,
which assumes that every element of `data' will be a list.  The symbol
`hline' is not a list.

>
> Finally, how am I then supposed to *ignore the header line*?  By adding
>
>   #+begin_src emacs-lisp
>   (setq table (cdr table))
>   #+end_src
>
> ?
>
> Do I have to do that explicitly in my code block, or is there an option for
> telling that to Babel?
>

Use the :colnames processing to strip the headings.

    #+begin_src emacs-lisp :var data=table :colnames yes
      data
    #+end_src

    #+RESULTS:
    : (("ABJ" 1) ("DEK" 2))

Best,

>
> Best regards,
>   Seb

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [Babel] Lisp error: (wrong-type-argument listp hline)

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> I think you're confused by headers which are re-added by the colnames
> machinery.

Blush!  I mixed the two in my head, yes.

> See the following which returns scalar output avoiding any colnames
> post-processing.

Why are you talking of *post* processing machinery for colnames?

The documentation[1] says that ":colnames no" means "no column name *pre*
processing takes place."

I may miss something important here.

> #+Property: results scalar
>
> #+name: table
> | Key | Value |
> |-----+-------|
> | ABJ |     1 |
> | DEK |     2 |
>
> #+begin_src emacs-lisp :var data=table :hlines no
>   data
> #+end_src
>
> #+RESULTS:
> : (("Key" "Value") ("ABJ" 1) ("DEK" 2))
>
> #+begin_src emacs-lisp :var data=table :hlines yes
>   data
> #+end_src
>
> #+RESULTS:
> : (("Key" "Value") hline ("ABJ" 1) ("DEK" 2))
>
>> * Set :hlines to "yes"
>>
>> `:hlines yes' should leave the horizontal line, but generates an error.
>>
>>   #+begin_src emacs-lisp :var data=table :results output :hlines yes
>>   (mapc (lambda (item) (princ (format "UPDATE dim SET val=%s WHERE code='%s'\n"
>>                                       (nth 1 item) (nth 0 item))))
>>    data)
>>   #+end_src
>
> This is not a babel error, this is an error in your code block body,
> which assumes that every element of `data' will be a list.  The symbol
> `hline' is not a list.

OK, that now becomes clear to me!

>> Finally, how am I then supposed to *ignore the header line*?  By adding
>>
>>   #+begin_src emacs-lisp
>>   (setq table (cdr table))
>>   #+end_src
>>
>> ?
>>
>> Do I have to do that explicitly in my code block, or is there an option for
>> telling that to Babel?
>
> Use the :colnames processing to strip the headings.
>
>     #+begin_src emacs-lisp :var data=table :colnames yes
>       data
>     #+end_src
>
>     #+RESULTS:
>     : (("ABJ" 1) ("DEK" 2))

I always wondered why emacs-lisp is the _only_ language with ":colnames no" as
its default. Is there a reason therefore?  If no really good reason, could we
suppress that?

Best regards,
  Seb

--
Sebastien Vauban

[1] http://orgmode.org/org.html#colnames

Re: [Babel] :colnames "no" no longer default for Emacs Lisp [Was] Lisp error: (wrong-type-argument listp hline)

[Eric Schulte]

>
> I always wondered why emacs-lisp is the _only_ language with ":colnames no" as
> its default. Is there a reason therefore?  If no really good reason, could we
> suppress that?
>

This seemed to make sense early on because Emacs Lisp could easily
process hlines itself, but at this point it adds more confusion than it
is worth.  I've reverted this default for elisp, hopefully it doesn't
break too many peoples existing Org-mode files.

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [Babel] :colnames "no" no longer default for Emacs Lisp [Was] Lisp error: (wrong-type-argument listp hline)

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> I always wondered why emacs-lisp is the _only_ language with ":colnames no"
>> as its default. Is there a reason therefore? If no really good reason, could
>> we suppress that?
>
> This seemed to make sense early on because Emacs Lisp could easily process
> hlines itself, but at this point it adds more confusion than it is worth.
> I've reverted this default for elisp.

Thanks. This looks more clear, now.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [Babel] :colnames "no" no longer default for Emacs Lisp [Was] Lisp error: (wrong-type-argument listp hline)

[Thomas S. Dye]

Hi Eric,

I think this breaks Marc-Oliver Ihm's lob-table-operations.org.

I use these a lot with #+call: lines.

Any tips on how to get the old behavior back? I tried :colnames no with
one of Marc-Oliver's code blocks, (and kept :colnames yes with my
#+call: line) but this didn't seem to change anything. Instead of the
column names from the original tables, which I used to get, I now get
names like "t1c2".

All the best,
Tom

Eric Schulte <schulte.eric@gmail.com> writes:

>>
>> I always wondered why emacs-lisp is the _only_ language with ":colnames no" as
>> its default. Is there a reason therefore?  If no really good reason, could we
>> suppress that?
>>
>
> This seemed to make sense early on because Emacs Lisp could easily
> process hlines itself, but at this point it adds more confusion than it
> is worth.  I've reverted this default for elisp, hopefully it doesn't
> break too many peoples existing Org-mode files.
>
> Best,

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [Babel] :colnames "no" no longer default for Emacs Lisp [Was] Lisp error: (wrong-type-argument listp hline)

[Eric Schulte]

tsd@tsdye.com (Thomas S. Dye) writes:

> Hi Eric,
>
> I think this breaks Marc-Oliver Ihm's lob-table-operations.org.
>
> I use these a lot with #+call: lines.
>
> Any tips on how to get the old behavior back?

You could add the following to your configuration which would replace
the previous default.

    (add-to-list 'org-babel-default-header-args:emacs-lisp
                 '(:colnames . "no"))
    (add-to-list 'org-babel-default-header-args:emacs-lisp
                 '(:hlines . "yes"))

You could also change the default emacs lisp header arguments for
certain files with property lines.

Best,

> I tried :colnames no with one of Marc-Oliver's code blocks, (and kept
> :colnames yes with my #+call: line) but this didn't seem to change
> anything. Instead of the column names from the original tables, which
> I used to get, I now get names like "t1c2".
>
> All the best,
> Tom
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>>>
>>> I always wondered why emacs-lisp is the _only_ language with ":colnames no" as
>>> its default. Is there a reason therefore?  If no really good reason, could we
>>> suppress that?
>>>
>>
>> This seemed to make sense early on because Emacs Lisp could easily
>> process hlines itself, but at this point it adds more confusion than it
>> is worth.  I've reverted this default for elisp, hopefully it doesn't
>> break too many peoples existing Org-mode files.
>>
>> Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D