"The reasonable man adapts himself to Emacs. The unreasonable man adapts Emacs to himself. Therefore all progress depends on the unreasonable man." With apologies to George Bernard Shaw.

Good one.. Laziness, hubris and impatience come to mind.

This is a project that I would like to see succeed. Emacs is my most important tool and the best improvement I can think for it to have is to have a better Lisp behind it. Threads, better error handling, tail-recursion, all would be huge wins.

Threading in emacs would be most excellent. Or, failing that, some sort of multi-process system under the hood ala Chrome.

I hate it when an inferior process locks emacs up.

Threading is actually already implemented on the "concurrency" branch. But for it to really be feasible, the code that's running in the thread needs to start using lexical scope, which is so new that not much code has adopted it yet.

Earlier I said it would be a bad idea to rewrite Emacs in Common Lisp. But starting from a machine-translated variant is a great idea.

I'm actually more interested in seeing the elisp to cl translator, though. Elisp and cl are quite similar, but not 100% compatible. And with no unit tests, it could be hard to get right.

For some reason it fascinates me that for a project promoting the strengths of Common Lisp, one would write the translator in Python.

EDIT: Apparently this is because GCC has a Python plugin API. All right, I guess if there was a CL plugin API then the author would write the translator in CL.

Is the intention to end up with all the emacs lisp code rewritten in Common Lisp? If so that may be misguided. emacs lisp is a DSL for making an extensible editor whilst Common Lisp is a general purpose programming language. There are good reasons for emacs lisp design decisions. Dynamic vs Lexical scope for example http://www.gnu.org/software/emacs/emacs-paper.html#SEC18

This is really awesome. I wonder if the progress will be shared, at some point.

As much as I enjoy writing emacs lisp, scripting in common lisp would have many benefits.

Nice to see s/he's following up with the initial idea. A fork would be interesting, but quite a bit of work, especially keeping up with the current emacs C language core development. Best of luck though, I look forward to what comes out of this.

To be successful, the fork does not have to keep up with current emacs C language development; it just has to attract enough users.

I guess I missed the part about writing a C translator, so that should make keeping up with the C code changes quite a bit easier.

shameless promotion:

if you are in the sf bay area & interested in lisp/smalltalk/fp and/or parallel/distributed computing please considering giving a ~5 minute educational lightning talk at the lisp meetup "revival" this saturday at the blackbox startup mansion in atherton

http://www.meetup.com/balisp/events/48872022/ http://balisp.org/

ahem cough cough ...free beer...