4 ms·
They could have solved this with porting from single-threaded Emacs Lisp to Guile[1] or a proper Common Lisp[2]. Sadly, both initiatives didn't get enough steam
by xvilka 5y ago
They could have solved this with porting from single-threaded Emacs Lisp to Guile[1] or a proper Common Lisp[2]. Sadly, both initiatives didn't get enough steam. Someone, though, started to rewrite Climacs in SBCL from scratch[3].
[1] https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
[2] https://www.cliki.net/cl-emacs https://www.cliki.net/cl-emacs
[3] https://github.com/robert-strandh/Second-Climacs https://github.com/robert-strandh/Second-Climacs
- ragnese 5y agoI'm not convinced that Elisp-the-language is really the limiting factor. I'm not an expert on the details- just a passive observer for several years. But, IIRC, Elisp recently got some kind of cooperative async stuff. Even before that, my understanding was that there are a lot of legacy architecture issues with Emacs, from its GUI model to the actual text data structures, that contribute to to latency/slowness. I think a full rewrite in any language would have likely brought about a better UI experience.