Comments on: Emacs and Common Lisp

By: Erik

Erik — Tue, 05 Feb 2013 01:02:56 +0000

Rob, one problem I have with emacs that could be solved is the entire process waiting for blocking i/o

By: adobriyan

adobriyan — Wed, 22 Aug 2012 15:41:12 +0000

Perl, not CL, as we all know, is Perfect Emacs Rewriting Language.

By: David

David — Sat, 31 Mar 2012 10:41:54 +0000

Rob: There’s a lot of subjectivity in the experience of performance. If you have “pretty crappy computers”, my guess (and I freely admit this is just a guess) would be that your expectations are low for performance — and with low expectations, they’ll get met.

(For more on subjective versus objective performance measurements, see, e.g., http://www.sigchi.org/chi95/proceedings/shortppr/gvk_bdy.htm )

I’m fairly new to emacs myself, but I can definitely say there are times when I find myself waiting for it to do something. To me, that’s essentially how I define a case of “experiencing performance issues” — if I’m waiting for the computer, it’s got a performance issue.

So, if you’ve “never ever experienced performance issues with Emacs”, I’d like to know what that means. Or, just to have you know that others of us have, and so for Tom, this may well be a “worth it” pursuit.

And as for which problems to solve, well, there are a lot of us humans about. You’re welcome to go solve others. I’m glad that Tom is working on the ones that *he sees* as a problem. If you’re trying to recruit his help on one of yours, that’s one thing… though perhaps he’ll be more effective at helping if he’s not waiting for his editor.

Anyway, Mostly what I want to say is Tom: Kudos on working on this. I’m excited to see what comes of it. I hope you’ll keep going… This seems like a lot of work, and I hope you have the persistence (and/or help, encouragement, etc.) to stick with it.

By: Rob

Rob — Thu, 26 Jan 2012 09:29:21 +0000

I can’t imagine a project this large ever getting finished, and I don’t believe the advantages are as great as you think they are.

First, performance really is not an issue anymore. Does anyone experience Emacs slowdown? I have pretty crappy computers and I’ve never ever experienced performance issues with Emacs.

Second, as others have said, a lot of the Emacs source code is not to do with Elisp but to do with highly performance-intensive areas such as redrawing. This code is complicated and I’m skeptical you could do a mostly automated and still performant conversion.

Third, it just isn’t worth it. OK, Elisp isn’t great, it’s not CL, but it’s good enough for what it does. There’s more important problems to solve.

By: The Cliffs of Inanity › Emacs and Common Lisp, Part 2

The Cliffs of Inanity › Emacs and Common Lisp, Part 2 — Wed, 25 Jan 2012 15:01:31 +0000

[...] is a followup to my earlier post on converting the Emacs C code into Common Lisp. This one is a bit more technical, diving into [...]

By: tom

tom — Sat, 21 Jan 2012 19:28:23 +0000

Yeah, the idea is to change the Emacs implementation while preserving the vast body of existing elisp.

By: ArneBabenhauserheide

ArneBabenhauserheide — Thu, 19 Jan 2012 13:46:24 +0000

Would all the thirdparty emacs extensions keep working in common lisp?

By: Miles Bader

Miles Bader — Tue, 17 Jan 2012 09:07:51 +0000

@Isaac
There is no license conflict between MIT and GNU GPL, you’re free to add MIT-licensed stuff to a GPL’d prog, and the result will still be under the GPL.

By: Isaac

Isaac — Fri, 13 Jan 2012 01:52:52 +0000

actually when I am thinking more about this, I am thinking actually add Lua support (embed Lua) directly into emacs could be a more interesting alternative … so that emacs can still use whatever it has, the raw c function and lisps, but with Lua, it may be easier for a lot of developers who are not fluent in lisp …

just some thought experiment and another hurdle is that Lua is MIT licence, vs GNU licence

By: Matt

Matt — Mon, 09 Jan 2012 22:44:28 +0000

@daimrod – Clojure’s native data structures are immutable, true. But we’re discussing a new implementation language for an elisp interpreter, not the possibility of replacing elisp with Clojure. Dynamic scope is a separate issue and I don’t see any reason a Clojure implementation wouldn’t support dynamic scope in elisp.

The a downside to choosing any JVM-based language would be the temptation to write emacs’s UI in a Java GUI toolkit. Emacs should still support a console UI and I have no idea how much trouble that would be from a JVM.