From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: [babel] Bugs for Emacs Lisp code blocks Date: Tue, 09 Apr 2013 10:13:59 +0200 Message-ID: <86wqsc6rzs.fsf@somewhere.org> References: <868v4v1x6k.fsf@somewhere.org> <871uamo4e9.fsf@gmail.com> <86d2u6z6kg.fsf@somewhere.org> <87d2u65dr1.fsf@gmail.com> <86ehek93w7.fsf@somewhere.org> <87a9p8zq7d.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, Eric Schulte wrote: > "Sebastien Vauban" writes: >> 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 thoug= ht >>>> 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 *unse= t* >>> 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 " :: Specifies to use 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 =3D:colnames=3D header argument (case 1) Same results for R and sh code blocks (first good news=C2=A0;-)) -- I'm avo= iding, on purpose, testing with Emacs Lisp... #+begin_src R :var data=3Dunset-colnames-example-input data #+end_src #+results: | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=3Dunset-colnames-example-input echo "$data" #+end_src #+results: | 1 | 2 | | 3 | 4 | ** Using =3D:colnames nil=3D header argument (case 5) Once again, R and sh blocks do produce the same results... #+begin_src R :var data=3Dunset-colnames-example-input :colnames nil data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=3Dunset-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 =3D:colnames yes=3D 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=3Dunset-colnames-example-input :colnames yes data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=3Dunset-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=3Dunset-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 lo= ng as case 1 and 5 are not the same in the above given example (for R and sh blocks). Best regards, Seb --=20 Sebastien Vauban