|
|
|
|
|
by Tenobrus
3293 days ago
|
|
I haven't taken an incredibly close look at this, but it seems like a pretty bad idea. Elisp is definitely not a great language, and I'd like an alternative as much as the next Emacs user. But I feel pretty strongly that any alternative has to be a Lisp, or very close to one. Code-is-data/data-is-code is very important for the more "config-file" aspects of configuring Emacs. Being able to use and write DSLs to succinctly encode exactly how you want aspects of the editor to behave is a critical strength. I've tried systems that were configurable in Python and other good-but-non-Lisp languages, and it's always much more annoying, because the language is (purposefully) limited w.r.t metaprogramming and possible DSLs. That's a good thing when optimizing for maintainability by others and obviousness, but not so much when optimizing for maximum personal customizability. Go seems like quite possibly the polar opposite of this, as far in the "keep it simple and understandable by literally everyone by cutting out many techniques for metaprograming and code reuse". Which perhaps is the point, but if so it seems like that point misses much of the draw of Emacs? While this is definitely impressive technically, I think Guile Emacs is a much more plausible option. |
|
Also, some of my projects that become bigger than 1000 LoC could benefit from static typing and (subjectively) better tooling.
By the way, I think extending Emacs in Racket would be great; just do not have an idea on how to implement that integration smoothly.