emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [babel] Bugs for Emacs Lisp code blocks


From: Eric Schulte
Subject: Re: [O] [babel] Bugs for Emacs Lisp code blocks
Date: Fri, 12 Apr 2013 16:09:22 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

"Sebastien Vauban" <address@hidden> writes:

> Hi Eric,
>
> Eric Schulte wrote:
>> "Sebastien Vauban" <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]