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
    4·
    24 days 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
      3·
      23 days 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.

      • Obin@feddit.org
        2·
        22 days ago

        As always in these cases, if the fork/rewrite is not compatible with the ecosystem, people won’t migrate and the fork/rewrite fails.

        neovim only got away with it because vimscript was so horrible and limited, the ecosystem already had an immense amount of churn and vim development was so centered around its developer. It was basically the perfect storm for a successful fork.

        But imagine what it would take for the emacs community to switch from GNU emacs. You’d have to rewrite your config, learn new workflows when your old ones were working perfectly fine, learn the new technical concepts, find replacements for all your packages that don’t even exist yet until a significant number of devs have switched over. Therefore the only forks that will ever succeed are the ones that start with the promise of full backwards-compatibility from the outset. And even then its more likely that the work of the fork gets incorporated back into GNU emacs at some point, as history shows.

        • Ferk@lemmy.ml
          1·
          19 days ago

          Yes. I think that’s likely why the goal for guilemacs has always been to be able to support elisp and make the transition as smooth as possible, without removing elisp support.

          One interesting thing about Guile’s VM (at least last time I checked) is that was designed to support multiple languages, not just Guile Scheme.

          Hmm… I wonder if that’s also why there was not a lot of push before, since this would open the doors to js in emacs too, which is a thing RMS did not want.

  • cdegroot@lemmy.ca
    2·
    16 days 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 :-)