There’s at least two ways you could keep the Emacs ecosystem while refreshing some of the other pieces (to build a new editor):
- You could reimplement the Emacs LISP VM and change what some of the native editor types refer to (buffer, point, window, etc.) so that they are interpreted in a “modern” UI setting. Maybe add some new opcodes while you’re at it to handle things like threading.
- You could fork emacs, strip out the display engine, and completely rewrite it (it’s notoriously complicated and probably not worth dealing with 50 years of legacy hacks).
Either of these options would give you a reasonable chance of skipping over the inherent complexity of the system without having to ditch all of the ecosystem packages), though they’re both still pretty involved.
A big part of the reason for this is you’d inherently end up losing some OS compatibility in the process, and maintaining compatibility is probably the biggest problem with making changes or updates to emacs. If you’re willing to ditch that burden, your options expand dramatically.
- You could reimplement the Emacs LISP VM and change what some of the native editor types refer to (buffer, point, window, etc.) so that they are interpreted in a “modern” UI setting. Maybe add some new opcodes while you’re at it to handle things like threading.
- You could fork emacs, strip out the display engine, and completely rewrite it (it’s notoriously complicated and probably not worth dealing with 50 years of legacy hacks).
Either of these options would give you a reasonable chance of skipping over the inherent complexity of the system without having to ditch all of the ecosystem packages), though they’re both still pretty involved.
A big part of the reason for this is you’d inherently end up losing some OS compatibility in the process, and maintaining compatibility is probably the biggest problem with making changes or updates to emacs. If you’re willing to ditch that burden, your options expand dramatically.