There have been quite a few attempts to re-implement (part of) Emacs' functionalities in languages other than C, like JEmacs, remacs, and lem. And we are seeing new efforts in EmacsConf 2024: rune 1, schemacs 2, and the revived Guilemacs 3. (Strictly speaking, Guilemacs is more a fork than a total rewrite, but anyway.) However, a complete rewrite of (GNU) Emacs 4 has always seemed like an insurmountable task, not just because writing editors is hard. This article aims to look into some of these difficulties and the Emacs designs (that of course have been exposed in some Emacs Lisp API) that lead to them.
  • cdegroot@lemmy.ca
    2·
    2 months ago

    While I won’t say that writing a text editor or rewriting (base) Emacs is easy, I think it is all about the ecosystem. There’s lots of Emacs reimplementations out there, some really good ones (like Lem), but they all have the same shortcoming: “no org mode”, “no magit”, and so on.

    Emacs has a truly enormous ecosystem and only a reimplementation that runs everything unchanged has a chance of attracting enough attention. There was a time that that was seen as a worthwhile venture: Elisp was limited and slow. However, now with CL compatibilty and native compilation, I don’t see it happening. Not in the sense of something standing up that can and will actually replace Emacs.

    Worse is better :-)