From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: [babel] Bugs for Emacs Lisp code blocks Date: Wed, 10 Apr 2013 09:54:58 +0200 Message-ID: <86mwt6ddm5.fsf@somewhere.org> References: <868v4v1x6k.fsf@somewhere.org> <871uamo4e9.fsf@gmail.com> <86d2u6z6kg.fsf@somewhere.org> <87d2u65dr1.fsf@gmail.com> <86wqsbcws2.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hi Eric, "Sebastien Vauban" wrote: > Eric Schulte wrote: >> "Sebastien Vauban" 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