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.
  • snikta@programming.dev
    0·
    1 year ago

    I vote for guilemacs. However, I wish C remains. There’s nothing wrong with C. And it feels like people are starting to realize that (again).

    • Ferk@lemmy.ml
      0·
      1 year ago

      I always thought guilemacs was meant to be the natural evolution. After all, GNU Guile was meant to be the extension language of choice from the GNU project… it’s just that it took way too long to mature, and now it’s taking even longer for guilemacs. I guess it’s a niche within a niche.

  • cdegroot@lemmy.ca
    0·
    1 year 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 :-)