[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp's future
From: |
Taylan Ulrich Bayirli/Kammer |
Subject: |
Re: Emacs Lisp's future |
Date: |
Wed, 17 Sep 2014 17:11:57 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: Taylan Ulrich Bayirli/Kammer <address@hidden>
>> Date: Wed, 17 Sep 2014 15:33:04 +0200
>> Cc: Christopher Allan Webber <address@hidden>,
>> Stefan Monnier <address@hidden>, address@hidden
>>
>> Note that Guile-Emacs runs existing Elisp as-is and is basically a
>> drop-in replacement.
>
> But that's not really true, is it? Just look at the changes made in
> the Guile-Emacs repo to core Lisp files, and you will see what I mean.
It's not a 100% drop-in replacement, that's true. I'll take a peek what
changes in Elisp files it did; the only one I remember at the moment is
Gnus directly writing out Elisp bytecode somewhere.
> Btw, I admit I don't completely understand what the wiki says about
> the problems with t and nil, but if that means you cannot say in
> Guile-Emacs something like
>
> (if (eq foo t) ...
>
> then there are more than 700 places in Emacs that will stop working.
(eq foo t) should always work. (eq foo nil) will only work if that
`nil' came from Elisp code; if it's a Scheme #f or '() in disguise, then
you need to make that (not foo) or (null foo) (both works in both
cases); anything but (eq foo nil).
Taylan
Re: Emacs Lisp's future, Eric Brown, 2014/09/17
Re: Emacs Lisp's future, Richard Stallman, 2014/09/17
Re: Emacs Lisp's future, Lars Magne Ingebrigtsen, 2014/09/17
Re: Emacs Lisp's future, Robin Templeton, 2014/09/20
Re: Guile emacs thread (again), LluĂs, 2014/09/17
Re: Guile emacs thread (again), Robin Templeton, 2014/09/18