Why isn't Lua even a choice? It's small, portable, easily embeddable, lightning fast, supports high-level functional programming idioms, and is extremely flexible in creating and enforcing policies (via metaprogramming).
Because Lua is a strictly less useful language than elisp. Among other things:
- It doesn't have macros.
- It doesn't have integers.
- It doesn't have arrays.
- It doesn't have lists.
- It doesn't have dynamic binding.
Also, its 1-based array-like hash tables are just ecchy.
I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby code is Lisp in Lua…).
> Because Lua is a strictly less useful language than elisp.
The word "useful" is too subjective to be useful here.
> - It doesn't have macros.
There's MetaLua for those who truly think they need macros. But in reality they're just a convenience.
> - It doesn't have integers.
Lua 5.3 is getting them.
> - It doesn't have arrays.
It has tables that function perfectly well as arrays.
> - It doesn't have lists.
Singly-linked-lists can easily be created using tables.
> - It doesn't have dynamic binding.
Thankfully!
> Also, its 1-based array-like hash tables are just ecchy.
This is purely an imaginary problem. Personally, I prefer 1-baed indices.
> I like Lua; it's cool for what it is (and in fact I'm currently writing some hobby code in it), but it's not Lisp (and in fact my current hobby code is Lisp in Lua…).
So, your favorite language is Lisp? Great. Except, favoritism and bias aren't really compatible with truly constructive criticism.
Feel free to tell me if I'm reading this wrong, but we're talking about Lua as a platform for re-implementing elisp, not as a replacement (completely ditching elisp is a non-starter for obvious reasons). And not having dynamic binding, no native support for the full numeric tower, not having a native list type, etc. would be serious road blocks for running elisp on the Lua VM that aren't there in Guile's case.
OTOH, Emacs isn't that accessible to many users, and its idiosynchrasies can be very offputting. I also quit Emacs after a while because I wasn't totally happy with it.
I think that's why there are so many attempts to built new extensible editors in other languages, like Eclipse, or that Ruby thing there once was (probably still is), or the Chromium/JS monster that was on HN recently.
I haven't yet found an editor I'm really happy with, so if I ever have time, I'll probably write my own as well. I'll lose the Emacs packages I don't use or even know about, but if you haven't bought into an existing ecosystem, that doesn't really matter. I'm unhappy enough with the existing systems that I don't mind throwing them away for something different.
One option is to have both Lua and Elisp, so that packages can be slowly migrated. Lua is small (so it doesn't incur a huge size cost to have 2 engines), fast (one reason why they want to switch, according to the author), and has a significantly large community. It also has coroutines, which is not what people dream of when people talk about concurrency but is probably good enough for a text editor (and avoids most sync problems). Furthermore, with this "dual-engine" strategy it would be a bad idea to choose a language similar to ELisp: it would cause a lot of confusion.
But I guess that Emacs on Lua wouldn't be Emacs anymore. That's the main objection.
