From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [babel] Bugs for Emacs Lisp code blocks Date: Mon, 15 Apr 2013 09:26:46 -0600 Message-ID: <87bo9fhl0c.fsf@gmail.com> References: <868v4v1x6k.fsf@somewhere.org> <871uamo4e9.fsf@gmail.com> <86d2u6z6kg.fsf@somewhere.org> <87d2u65dr1.fsf@gmail.com> <86wqsbcws2.fsf@somewhere.org> <86mwt6ddm5.fsf@somewhere.org> <87ehefe5kn.fsf@gmail.com> <86vc7nevhb.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:44724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URlKK-00087C-AR for emacs-orgmode@gnu.org; Mon, 15 Apr 2013 11:28:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URlKF-0002v6-G1 for emacs-orgmode@gnu.org; Mon, 15 Apr 2013 11:28:16 -0400 Received: from mail-pb0-f41.google.com ([209.85.160.41]:62617) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URlKF-0002uw-AB for emacs-orgmode@gnu.org; Mon, 15 Apr 2013 11:28:11 -0400 Received: by mail-pb0-f41.google.com with SMTP id mc17so2576914pbc.0 for ; Mon, 15 Apr 2013 08:28:10 -0700 (PDT) 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@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Sebastien Vauban Cc: emacs-orgmode@gnu.org "Sebastien Vauban" 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