[babel] Bugs for Emacs Lisp code blocks

[babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Hello,

Here are some tests with the colnames parameter *and* the Emacs Lisp language
for the "echo" code block. They're giving results I don't understand...

Note that functionally the same "echo" code block in other languages (I tested
R and sh) does return the expected results.

* Input table

Consider this input table, with 2 rows, and a header row.

#+name: input
| id   | var1 |
|------+------|
| obs1 | foo  |
| obs2 | bar  |

* Interactive calls

Let's try different calls, changing the =:colnames= parameter.

1. Using =:colnames yes=

   #+name: ELisp-echo-1
   #+begin_src emacs-lisp :var data=input :colnames yes :exports results
   data
   #+end_src

   #+results: ELisp-echo-1
   | id   | var1 |
   |------+------|
   | obs1 | foo  |
   | obs2 | bar  |

   OK; the result is what I expected.

2. Using =:colnames no=

   #+name: ELisp-echo-2
   #+begin_src emacs-lisp :var data=input :colnames no :exports results
   data
   #+end_src

   #+results: ELisp-echo-2
   | id   | var1 |
   |------+------|
   | obs1 | foo  |
   | obs2 | bar  |

   Here, I was expecting:

   | id   | var1 |
   | obs1 | foo  |
   | obs2 | bar  |

3. Using no =:colnames= header argument

   #+name: ELisp-echo-3
   #+begin_src emacs-lisp :var data=input :exports results
   data
   #+end_src

   #+results: ELisp-echo-3
   | id   | var1 |
   |------+------|
   | obs1 | foo  |
   | obs2 | bar  |

   Here, I was expecting:

   | obs1 | foo |
   | obs2 | bar |

* Call at export time

#+call: ELisp-echo-1(data=input)

I get:

| id   | var1 |
| id   | var1 |
| obs1 | foo  |
| obs2 | bar  |

Not at all what I was expecting...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Eric Schulte]

Hi Seb,

Emacs Lisp is an exception in terms of colname processing, it has
default header arguments set to pass column names through to the code
block, where the processing may be done trivially in Emacs Lisp.

> #+name: input
> | id   | var1 |
> |------+------|
> | obs1 | foo  |
> | obs2 | bar  |

[...]

>    #+name: ELisp-echo-1
>    #+begin_src emacs-lisp :var data=input :colnames yes :exports results
>    data
>    #+end_src

[...]

> * Call at export time
>
> #+call: ELisp-echo-1(data=input)
>
> I get:
>
> | id   | var1 |
> | id   | var1 |
> | obs1 | foo  |
> | obs2 | bar  |
>
> Not at all what I was expecting...

Agreed, I've just pushed up a fix, so the following now works.

    #+name: input
    | id   | var1 |
    |------+------|
    | obs1 | foo  |
    | obs2 | bar  |

    #+name: ELisp-echo-1
    #+begin_src emacs-lisp :var data=input :exports results
    data
    #+end_src

    #+call: ELisp-echo-1(data=input)

    #+RESULTS: ELisp-echo-1(data=input)
    | id   | var1 |
    |------+------|
    | obs1 | foo  |
    | obs2 | bar  |

Thanks for pointing this out.

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

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> Emacs Lisp is an exception in terms of colname processing, it has
> default header arguments set to pass column names through to the code
> block, where the processing may be done trivially in Emacs Lisp.

OK, but I don't understand the precedence of header arguments. I thought that
a header argument given on the code block preempted all the other values
(system-wide default for all languages, language defaults, file-wide
arguments, and subtree arguments).

Why isn't this true here as well?

>> * Call at export time
>>
>> #+call: ELisp-echo-1(data=input)
>>
>> I get:
>>
>> | id   | var1 |
>> | id   | var1 |
>> | obs1 | foo  |
>> | obs2 | bar  |
>>
>> Not at all what I was expecting...
>
> Agreed, I've just pushed up a fix, so the following now works.
>
>     #+name: input
>     | id   | var1 |
>     |------+------|
>     | obs1 | foo  |
>     | obs2 | bar  |
>
>     #+name: ELisp-echo-1
>     #+begin_src emacs-lisp :var data=input :exports results
>     data
>     #+end_src
>
>     #+call: ELisp-echo-1(data=input)
>
>     #+RESULTS: ELisp-echo-1(data=input)
>     | id   | var1 |
>     |------+------|
>     | obs1 | foo  |
>     | obs2 | bar  |
>
> Thanks for pointing this out.

Here, I understand that the #+call line uses the default header argument set
on the language. So, that seems right to me as well...

Thanks.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>> Emacs Lisp is an exception in terms of colname processing, it has
>> default header arguments set to pass column names through to the code
>> block, where the processing may be done trivially in Emacs Lisp.
>
> OK, but I don't understand the precedence of header arguments. I thought that
> a header argument given on the code block preempted all the other values
> (system-wide default for all languages, language defaults, file-wide
> arguments, and subtree arguments).
>
> Why isn't this true here as well?
>

That is what is happening here, although combinations of :hlines and
:colnames can be tricky.  Especially weird, is that if you want to
*unset* a header argument which is set at a higher level, you need to
set it to '(), as in ":colnames '()".

Cheers,

>
>>> * Call at export time
>>>
>>> #+call: ELisp-echo-1(data=input)
>>>
>>> I get:
>>>
>>> | id   | var1 |
>>> | id   | var1 |
>>> | obs1 | foo  |
>>> | obs2 | bar  |
>>>
>>> Not at all what I was expecting...
>>
>> Agreed, I've just pushed up a fix, so the following now works.
>>
>>     #+name: input
>>     | id   | var1 |
>>     |------+------|
>>     | obs1 | foo  |
>>     | obs2 | bar  |
>>
>>     #+name: ELisp-echo-1
>>     #+begin_src emacs-lisp :var data=input :exports results
>>     data
>>     #+end_src
>>
>>     #+call: ELisp-echo-1(data=input)
>>
>>     #+RESULTS: ELisp-echo-1(data=input)
>>     | id   | var1 |
>>     |------+------|
>>     | obs1 | foo  |
>>     | obs2 | bar  |
>>
>> Thanks for pointing this out.
>
> Here, I understand that the #+call line uses the default header argument set
> on the language. So, that seems right to me as well...
>
> Thanks.
>
> Best regards,
>   Seb

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

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Eric Schulte wrote:
>>> Emacs Lisp is an exception in terms of colname processing, it has default
>>> header arguments set to pass column names through to the code block, where
>>> the processing may be done trivially in Emacs Lisp.
>>
>> OK, but I don't understand the precedence of header arguments. I thought
>> that a header argument given on the code block preempted all the other
>> values (system-wide default for all languages, language defaults, file-wide
>> arguments, and subtree arguments).
>>
>> Why isn't this true here as well?
>
> That is what is happening here, although combinations of :hlines and
> :colnames can be tricky. Especially weird, is that if you want to *unset* a
> header argument which is set at a higher level, you need to set it to '(),
> as in ":colnames '()".

Much clearer, but not yet crystal-clear for me...

Let me explain. AFAICT, there were 5 possibles values of the ":colnames"
header argument:

- no header argument :: (default for all languages but Emacs Lisp)
- ":colnames no" :: (default for Emacs Lisp code blocks)
- ":colnames yes" :: Tells Org Babel that your first row contains column
  names.
- ":colnames <LIST>" :: Specifies to use <LIST> as column names.
- ":colnames nil" :: Same as ":colnames yes".

Right?

Now, indeed, your trick with ":colnames '()" (or even ":colnames ()"...) does
work well for Emacs-Lisp...

Though, I thought that "()" was equivalent to "nil", but it seems not to be
the case, then. Is it because of some sort of type coercion, that would
convert nil as a string or something along such lines?

Extra question: when do we have to use such a trick?  When the value can be a
list of things?  If yes, why are you talking of ":hlines" -- there is no list
argument there?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Eric Schulte]

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

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>>> Eric Schulte wrote:
>>>> Emacs Lisp is an exception in terms of colname processing, it has default
>>>> header arguments set to pass column names through to the code block, where
>>>> the processing may be done trivially in Emacs Lisp.
>>>
>>> OK, but I don't understand the precedence of header arguments. I thought
>>> that a header argument given on the code block preempted all the other
>>> values (system-wide default for all languages, language defaults, file-wide
>>> arguments, and subtree arguments).
>>>
>>> Why isn't this true here as well?
>>
>> That is what is happening here, although combinations of :hlines and
>> :colnames can be tricky. Especially weird, is that if you want to *unset* a
>> header argument which is set at a higher level, you need to set it to '(),
>> as in ":colnames '()".
>
> Much clearer, but not yet crystal-clear for me...
>
> Let me explain. AFAICT, there were 5 possibles values of the ":colnames"
> header argument:
>
> - no header argument :: (default for all languages but Emacs Lisp)
> - ":colnames no" :: (default for Emacs Lisp code blocks)
> - ":colnames yes" :: Tells Org Babel that your first row contains column
>   names.
> - ":colnames <LIST>" :: Specifies to use <LIST> as column names.
> - ":colnames nil" :: Same as ":colnames yes".
>
>
> Right?
>

Almost, values 1 (none) and 5 (nil) are the same.

>
> Now, indeed, your trick with ":colnames '()" (or even ":colnames
> ()"...) does work well for Emacs-Lisp...
>
> Though, I thought that "()" was equivalent to "nil", but it seems not
> to be the case, then. Is it because of some sort of type coercion,
> that would convert nil as a string or something along such lines?
>

See "Emacs Lisp evaluation of variables" in (info "(org)var").  We could
add nil as a special exception, but that might be surprising to some
people.

>
> Extra question: when do we have to use such a trick?  When the value can be a
> list of things?  If yes, why are you talking of ":hlines" -- there is no list
> argument there?
>

Whenever you want to "unset" a header argument, which has a value set at
some higher level.


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

** unset the colnames header argument
#+name: unset-colnames-example-input
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

Unlike most code blocks, Emacs Lisp has colnames set to "yes" in its
default header arguments.

#+begin_src emacs-lisp
  org-babel-default-header-args:emacs-lisp
#+end_src

#+RESULTS:
| (:hlines . yes) | (:colnames . no) |

As a result it has the following behavior by default.

#+begin_src emacs-lisp :var data=unset-colnames-example-input
  data
#+end_src

#+RESULTS:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

If we wanted to unset this value, we could do the following.

#+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames ()
  data
#+end_src

#+RESULTS:
| 1 | 2 |
| 3 | 4 |

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


Cheers,

>
> Best regards,
>   Seb

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

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Eric Schulte wrote:
>>> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>>> Eric Schulte wrote:
>>>>> Emacs Lisp is an exception in terms of colname processing, it has
>>>>> default header arguments set to pass column names through to the code
>>>>> block, where the processing may be done trivially in Emacs Lisp.
>>>>
>>>> OK, but I don't understand the precedence of header arguments. I thought
>>>> that a header argument given on the code block preempted all the other
>>>> values (system-wide default for all languages, language defaults,
>>>> file-wide arguments, and subtree arguments).
>>>>
>>>> Why isn't this true here as well?
>>>
>>> That is what is happening here, although combinations of :hlines and
>>> :colnames can be tricky. Especially weird, is that if you want to *unset*
>>> a header argument which is set at a higher level, you need to set it to
>>> '(), as in ":colnames '()".
>>
>> Much clearer, but not yet crystal-clear for me...
>>
>> Let me explain. AFAICT, there were 5 possibles values of the ":colnames"
>> header argument:
>>
>> - no header argument :: (default for all languages but Emacs Lisp)
>> - ":colnames no" :: (default for Emacs Lisp code blocks)
>> - ":colnames yes" :: Tells Org Babel that your first row contains column
>>   names.
>> - ":colnames <LIST>" :: Specifies to use <LIST> as column names.
>> - ":colnames nil" :: Same as ":colnames yes".
>>
>> Right?
>
> Almost, values 1 (none) and 5 (nil) are the same.

I don't share your view about this last statement.

** Input table

#+name: unset-colnames-example-input
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

** Having no =:colnames= header argument (case 1)

Same results for R and sh code blocks (first good news ;-)) -- I'm avoiding,
on purpose, testing with Emacs Lisp...

#+begin_src R :var data=unset-colnames-example-input
  data
#+end_src

#+results:
| 1 | 2 |
| 3 | 4 |

#+begin_src sh :var data=unset-colnames-example-input
  echo "$data"
#+end_src

#+results:
| 1 | 2 |
| 3 | 4 |

** Using =:colnames nil= header argument (case 5)

Once again, R and sh blocks do produce the same results...

#+begin_src R :var data=unset-colnames-example-input :colnames nil
  data
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

#+begin_src sh :var data=unset-colnames-example-input :colnames nil
  echo "$data"
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

... but they are _not_ equivalent to the "no header argument" (case 1).

** Using =:colnames yes= header argument (case 3)

On the contrary, case 5 is equivalent to the case 3: same results as
":colnames yes".

#+begin_src R :var data=unset-colnames-example-input :colnames yes
  data
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

#+begin_src sh :var data=unset-colnames-example-input :colnames yes
  echo "$data"
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

>> Now, indeed, your trick with ":colnames '()" (or even ":colnames
>> ()"...) does work well for Emacs-Lisp...
>>
>> Though, I thought that "()" was equivalent to "nil", but it seems not
>> to be the case, then. Is it because of some sort of type coercion,
>> that would convert nil as a string or something along such lines?
>
> See "Emacs Lisp evaluation of variables" in (info "(org)var").

Not sure to find what you want me to read in that page...

> We could add nil as a special exception, but that might be surprising to
> some people.

As far as the Lisp interpreter is concerned, () and nil are the same, right?
Then, why do you talk of adding a special exception?  Maybe, I don't
understand your point because I'm missing the context info you wanted me to
read just above?

>> Extra question: when do we have to use such a trick?  When the value can be a
>> list of things?  If yes, why are you talking of ":hlines" -- there is no list
>> argument there?
>
> Whenever you want to "unset" a header argument, which has a value set at
> some higher level.
>
> ** unset the colnames header argument
> #+name: unset-colnames-example-input
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> Unlike most code blocks, Emacs Lisp has colnames set to "yes" in its
> default header arguments. [...]
> If we wanted to unset this value, we could do the following.
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames ()
>   data
> #+end_src
>
> #+RESULTS:
> | 1 | 2 |
> | 3 | 4 |

This is clear -- thanks! -- but it does not unset the header argument as long
as case 1 and 5 are not the same in the above given example (for R and sh
blocks).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Eric Schulte wrote:
>>> Emacs Lisp is an exception in terms of colname processing, it has default
>>> header arguments set to pass column names through to the code block, where
>>> the processing may be done trivially in Emacs Lisp.
>>
>> OK, but I don't understand the precedence of header arguments. I thought
>> that a header argument given on the code block preempted all the other
>> values (system-wide default for all languages, language defaults, file-wide
>> arguments, and subtree arguments).
>>
>> Why isn't this true here as well?
>
> That is what is happening here, although combinations of :hlines and
> :colnames can be tricky. Especially weird, is that if you want to *unset* a
> header argument which is set at a higher level, you need to set it to '(),
> as in ":colnames '()".

#+name: unset-colnames-example-input
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

** Having no =:colnames= header argument (case 1)

I understand that the following example does have =:colnames= set to =yes=: it is
neither unset nor changed on the code block specification.

#+begin_src emacs-lisp :var data=unset-colnames-example-input
  data
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

Hence, this result is what is expected.

** Using =:colnames no= header argument (case 2)

#+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no
  data
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

Here, I still don't understand why I do see the table header line: I did
change the default =:colnames yes= specification to =:colnames no= on the code
block. I did override the default value. Why is the =no= argument not
respected?

** Using =:colnames yes= header argument (case 3)

#+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames yes
  data
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

Here, the =:colnames yes= specification is simply redundant to what's specified
for the emacs-lisp language. In all cases, the results is what is should be.

** Using =:colnames nil= header argument (case 5)

#+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames nil
  data
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

As written in my previous post, =:colnames nil= is equivalent to =:colnames yes=
in Emacs Lisp, R and sh code blocks -- at least.

(Still) not clear to me -- sorry to be stubborn.

** Using =:colnames ()= header argument (case 6)

As you told me, to "unset" the =:colnames yes= header argument, we must use:

#+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames ()
  data
#+end_src

#+results:
| 1 | 2 |
| 3 | 4 |

That does work.

** Using =:colnames ()= header argument (case 7)

So does the quoted empty list version...

#+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames '()
  data
#+end_src

#+results:
| 1 | 2 |
| 3 | 4 |

What is still unclear to me as well, is why =()= and =nil= aren't the same from
Babel's point of view?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Hi Eric,

"Sebastien Vauban" wrote:
> Eric Schulte wrote:
>> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>> Eric Schulte wrote:
>>>> Emacs Lisp is an exception in terms of colname processing, it has default
>>>> header arguments set to pass column names through to the code block,
>>>> where the processing may be done trivially in Emacs Lisp.
>>>
>>> OK, but I don't understand the precedence of header arguments. I thought
>>> that a header argument given on the code block preempted all the other
>>> values (system-wide default for all languages, language defaults,
>>> file-wide arguments, and subtree arguments).
>>>
>>> Why isn't this true here as well?
>>
>> That is what is happening here, although combinations of :hlines and
>> :colnames can be tricky. Especially weird, is that if you want to *unset* a
>> header argument which is set at a higher level, you need to set it to '(),
>> as in ":colnames '()".
>
> #+name: unset-colnames-example-input
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> ** Having no =:colnames= header argument (case 1)
>
> I understand that the following example does have =:colnames= set to =yes=:
> it is neither unset nor changed on the code block specification.
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> Hence, this result is what is expected.
>
> ** Using =:colnames no= header argument (case 2)
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> Here, I still don't understand why I do see the table header line: I did
> change the default =:colnames yes= specification to =:colnames no= on the
> code block. I did override the default value. Why is the =no= argument not
> respected?

This still escapes me.

> ** Using =:colnames ()= header argument (case 6)
>
> As you told me, to "unset" the =:colnames yes= header argument, we must use:
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames ()
>   data
> #+end_src
>
> #+results:
> | 1 | 2 |
> | 3 | 4 |
>
> That does work.
>
> What is still unclear to me as well, is why =()= and =nil= aren't the same
> from Babel's point of view?

However, I think I understood this one: it is because nil is interpreted as a
string, not as the empty list; right?

That's because strings aren't quoted, right?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Eric Schulte]

>>>
>>> Much clearer, but not yet crystal-clear for me...
>>>
>>> Let me explain. AFAICT, there were 5 possibles values of the ":colnames"
>>> header argument:
>>>
>>> - no header argument :: (default for all languages but Emacs Lisp)
>>> - ":colnames no" :: (default for Emacs Lisp code blocks)
>>> - ":colnames yes" :: Tells Org Babel that your first row contains column
>>>   names.
>>> - ":colnames <LIST>" :: Specifies to use <LIST> as column names.
>>> - ":colnames nil" :: Same as ":colnames yes".
>>>
>>> Right?
>>
>> Almost, values 1 (none) and 5 (nil) are the same.
>
> I don't share your view about this last statement.
>
> ** Input table
>
> #+name: unset-colnames-example-input
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> ** Having no =:colnames= header argument (case 1)
>
> Same results for R and sh code blocks (first good news ;-)) -- I'm avoiding,
> on purpose, testing with Emacs Lisp...
>
> #+begin_src R :var data=unset-colnames-example-input
>   data
> #+end_src
>
> #+results:
> | 1 | 2 |
> | 3 | 4 |
>
> #+begin_src sh :var data=unset-colnames-example-input
>   echo "$data"
> #+end_src
>
> #+results:
> | 1 | 2 |
> | 3 | 4 |
>

Looks good.

>
> ** Using =:colnames nil= header argument (case 5)
>
> Once again, R and sh blocks do produce the same results...
>
> #+begin_src R :var data=unset-colnames-example-input :colnames nil
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> #+begin_src sh :var data=unset-colnames-example-input :colnames nil
>   echo "$data"
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> ... but they are _not_ equivalent to the "no header argument" (case 1).
>

As I believe I mentioned "nil" on a header argument is not interpreted
as the lisp literal `nil'.  To pass an empty argument to a code block
you should do ":colnames '()", an obscure syntax for an obscure thing.

>
> ** Using =:colnames yes= header argument (case 3)
>
> On the contrary, case 5 is equivalent to the case 3: same results as
> ":colnames yes".
>
> #+begin_src R :var data=unset-colnames-example-input :colnames yes
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> #+begin_src sh :var data=unset-colnames-example-input :colnames yes
>   echo "$data"
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>

Because the "nil" you specified above is just treated as a string.  You
get the same thing with.

#+begin_src sh :var data=unset-colnames-example-input :colnames sure
  echo "$data"
#+end_src

#+RESULTS:
| a | b |
|---+---|
| 1 | 2 |
| 3 | 4 |

Cheers,

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

Re: [babel] Bugs for Emacs Lisp code blocks

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>>> Eric Schulte wrote:
>>>> Emacs Lisp is an exception in terms of colname processing, it has default
>>>> header arguments set to pass column names through to the code block, where
>>>> the processing may be done trivially in Emacs Lisp.
>>>
>>> OK, but I don't understand the precedence of header arguments. I thought
>>> that a header argument given on the code block preempted all the other
>>> values (system-wide default for all languages, language defaults, file-wide
>>> arguments, and subtree arguments).
>>>
>>> Why isn't this true here as well?
>>
>> That is what is happening here, although combinations of :hlines and
>> :colnames can be tricky. Especially weird, is that if you want to *unset* a
>> header argument which is set at a higher level, you need to set it to '(),
>> as in ":colnames '()".
>
> #+name: unset-colnames-example-input
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>

I thought you said you weren't going to try this with Emacs Lisp. :)

>
> ** Having no =:colnames= header argument (case 1)
>
> I understand that the following example does have =:colnames= set to =yes=: it is
> neither unset nor changed on the code block specification.
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> Hence, this result is what is expected.
>
> ** Using =:colnames no= header argument (case 2)
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> Here, I still don't understand why I do see the table header line: I did
> change the default =:colnames yes= specification to =:colnames no= on the code
> block. I did override the default value. Why is the =no= argument not
> respected?
>

Because 'hlines is set to yes by default in
`org-babel-default-header-args:emacs-lisp'.

>
> ** Using =:colnames yes= header argument (case 3)
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames yes
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> Here, the =:colnames yes= specification is simply redundant to what's specified
> for the emacs-lisp language. In all cases, the results is what is should be.
>

agreed

>
> ** Using =:colnames nil= header argument (case 5)
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames nil
>   data
> #+end_src
>
> #+results:
> | a | b |
> |---+---|
> | 1 | 2 |
> | 3 | 4 |
>
> As written in my previous post, =:colnames nil= is equivalent to =:colnames yes=
> in Emacs Lisp, R and sh code blocks -- at least.
>

answered in my previous reply.

>
> (Still) not clear to me -- sorry to be stubborn.
>
> ** Using =:colnames ()= header argument (case 6)
>
> As you told me, to "unset" the =:colnames yes= header argument, we must use:
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames ()
>   data
> #+end_src
>
> #+results:
> | 1 | 2 |
> | 3 | 4 |
>
> That does work.
>

Yes, this answers your question immediately above.

>
> ** Using =:colnames ()= header argument (case 7)
>
> So does the quoted empty list version...
>
> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames '()
>   data
> #+end_src
>
> #+results:
> | 1 | 2 |
> | 3 | 4 |
>
> What is still unclear to me as well, is why =()= and =nil= aren't the same from
> Babel's point of view?
>

Look in the manual at the description of what causes header arguments to
be interpreted as Emacs Lisp.

Cheers,

>
> Best regards,
>   Seb

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

Re: [babel] Bugs for Emacs Lisp code blocks

[Eric Schulte]

>> ** Using =:colnames no= header argument (case 2)
>>
>> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no
>>   data
>> #+end_src
>>
>> #+results:
>> | a | b |
>> |---+---|
>> | 1 | 2 |
>> | 3 | 4 |
>>
>> Here, I still don't understand why I do see the table header line: I
>> did change the default =:colnames yes= specification to =:colnames
>> no= on the code block. I did override the default value. Why is the
>> =no= argument not respected?
>
> This still escapes me.
>

Answered in my previous reply.

>
>> ** Using =:colnames ()= header argument (case 6)
>>
>> As you told me, to "unset" the =:colnames yes= header argument, we must use:
>>
>> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames ()
>>   data
>> #+end_src
>>
>> #+results:
>> | 1 | 2 |
>> | 3 | 4 |
>>
>> That does work.
>>
>> What is still unclear to me as well, is why =()= and =nil= aren't the same
>> from Babel's point of view?
>
> However, I think I understood this one: it is because nil is interpreted as a
> string, not as the empty list; right?
>
> That's because strings aren't quoted, right?
>

Yes.

Cheers,

>
> Best regards,
>   Seb

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

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Eric,

Eric Schulte wrote:
>>>> Let me explain. AFAICT, there were 5 possibles values of the ":colnames"
>>>> header argument:
>>>>
>>>> - no header argument :: (default for all languages but Emacs Lisp)
>>>> - ":colnames no" :: (default for Emacs Lisp code blocks)
>>>> - ":colnames yes" :: Tells Org Babel that your first row contains column
>>>>   names.
>>>> - ":colnames <LIST>" :: Specifies to use <LIST> as column names.
>>>> - ":colnames nil" :: Same as ":colnames yes".
>>>>
>>>> Right?
>>>
>>> Almost, values 1 (none) and 5 (nil) are the same.
>>
>> I don't share your view about this last statement.
>
> As I believe I mentioned "nil" on a header argument is not interpreted
> as the lisp literal `nil'.  To pass an empty argument to a code block
> you should do ":colnames '()", an obscure syntax for an obscure thing.

I do now share your view with your precision on using

- :colnames '() or
- :colnames ()

to pass an empty argument.

Are both version above really equivalent (they _do_ behave the same in my tests,
but I'm wondering for the future)?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Eric,

Eric Schulte wrote:
>> ** Using =:colnames no= header argument (case 2)
>>
>> #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no
>>   data
>> #+end_src
>>
>> #+results:
>> | a | b |
>> |---+---|
>> | 1 | 2 |
>> | 3 | 4 |
>>
>> Here, I still don't understand why I do see the table header line: I did
>> change the default =:colnames yes= specification to =:colnames no= on the code
>> block. I did override the default value. Why is the =no= argument not
>> respected?
>
> Because 'hlines is set to yes by default in
> `org-babel-default-header-args:emacs-lisp'.

I missed the cumulative effect of hlines on the behavior of colnames.
Yes, setting hlines to no does solve the problem for Emacs Lisp code blocks.

Thanks a lot.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Sebastien Vauban]

Eric,

Eric Schulte wrote:
>>> What is still unclear to me as well, is why =()= and =nil= aren't the same
>>> from Babel's point of view?
>>
>> However, I think I understood this one: it is because nil is interpreted as a
>> string, not as the empty list; right?
>>
>> That's because strings aren't quoted, right?
>
> Yes.

Apart from the automatic (and, maybe, sometimes unwished) coercion of a symbol
into a string (case of `nil'), are you aware of other tricky stuff?

For my own understanding, why didn't we force the user to quote all strings,
and avoid the above problem?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [babel] Bugs for Emacs Lisp code blocks

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Eric,
>
> Eric Schulte wrote:
>>>> What is still unclear to me as well, is why =()= and =nil= aren't the same
>>>> from Babel's point of view?
>>>
>>> However, I think I understood this one: it is because nil is interpreted as a
>>> string, not as the empty list; right?
>>>
>>> That's because strings aren't quoted, right?
>>
>> Yes.
>
> Apart from the automatic (and, maybe, sometimes unwished) coercion of a symbol
> into a string (case of `nil'), are you aware of other tricky stuff?
>
> For my own understanding, why didn't we force the user to quote all strings,
> and avoid the above problem?
>

We have to consider named blocks or data as well as strings and Emacs
Lisp.

>
> Best regards,
>   Seb

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