4 ms·

Because it is a completely different language and would require rewriting all of the thousands of packages by hand (and centuries of human labor)?

thejdude 12y ago
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.
linguafranca 12y ago
Good point. But it's not unheard of to write a transpiler from Language X to Lua. See the VimL compiler in NeoVim[1]. [1]: https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-are-distinct-languages-with-different-semantics-how-can-lua-be-used-as-a-runtime-for-vimscript https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-...
astrobe_ 12y ago
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.

thejdude 12y ago

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.

linguafranca 12y ago

Good point. But it's not unheard of to write a transpiler from Language X to Lua. See the VimL compiler in NeoVim[1]. [1]: https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-are-distinct-languages-with-different-semantics-how-can-lua-be-used-as-a-runtime-for-vimscript https://github.com/neovim/neovim/wiki/FAQ#lua-and-vimscript-...

astrobe_ 12y ago

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.