Making Emacs truly modular?

[cyruseuros]

Once the ship of Theseus task of replacing all the C is complete
(currently in the process of picking up Rust properly to help out with
this), will Remacs make an effor to make Emacs truly modular?

If we made bare-bones Emacs cargo-installable there would be quite a
few benefits (at least to my novice eyes):

1. Minimal Emacs for minimal systems.
2. Replacing --with-* compilation flags with cargo crates would make
   adding features much more straightforward.
3. User-contributed, performance-critical code could also be packaged
   as cargo crates (they already are, to some extent, for which I
   applaud you). But if everything including core Emacs were cargo
   installable, ugly (but currently necessary) elisp wrappers like
   this
   would not need to be reinvented every time. Instead, a core Remacs
   engine could handle this.
4. CI would be so much easier. Think
   evm but with Rust's excellent
   packaging.
5. Emacs doesn't really have one lingua franca (elisp). It has two
   --- elisp and C (hopefully Rust at some point in the
   future). Adding features to the core is prohibitively difficult as
   things stand. If it were just a simple matter of following a guide
   to making a Remacs crate, then Emacs would be truly extensible,
   and even more Emacs-y.

[phrxmd]

A better GUI would be nice, something like QML for which there is Rust support.

[cireu]

Seperate Elisp VM from Emacs is also wonderful!

[shaleh]

I remember responding to this but I am not seeing my comment.....
(Everywhere I say C code below is just as true for Rust)

When there is C code it exists for two main reasons:

Access. The elisp code might not see the needed code. For instance, if the new function needs code from a C library. Unless that C library is exposed as a elisp module, C code needs to be written to use it. Most of the UI falls in this category for instance.

Efficiency. There is a cost to transporting C data structures into Elisp. Sometimes that cost is too high for frequently used functions. This is why many primitives are written in C.

For code which is in C solely due to access to a library, there is a good chance this could be pulled out into some form of package that wraps the library. There is already some support for this in Emacs today. More code could be moved in that direction to limit the size of Emacs internals. Like say, zlib/gzip for instance. Or XML.

The code which is C today so it can access the guts of Emacs is going to be harder to pull out. A well definite interface would need to be made. Similarly, code in C for efficiency might be stuck there and pulling it onto other packages may not help much. Case by case there.

I'd love to see Remacs become a place to experiment with better UI so we can get away from the early 90s UNIX feel. While I personally do not use it the UI is a great way to bring people in.

Making the VM and interpreter parts of emacs clearly defined would definitely be an improvement. This would help draw a line around various pieces of static variables, globals, etc. etc.

[XVilka]

It was mentioned in the EmacsConf'19 by @pmetzger

[cyruseuros]

While we're talking (G)UI, iced looks promising and just got a pretty solid backer (the maintainers employer). But this is a tangent. Should there be a super-issue for tracking progress on this? @shaleh I could do a quick write-up based on the above

[shaleh]

Our focus today is getting to a stable place close to the head of Emacs. Then we need to move the exposed lisp functions written in C to Rust. Once that is complete and we have a Rust "shell" over a C core we can start pulling pieces out into crates. My expectation is that eventually we will have things like remacs-mac-gui as a crate which implements an interface for GUI along with remacs-gtk and remacs-windows. The same goes for other parts of the --with-* in the configure script as @jjzmajic suggests. Let's be honest, configure --with-stuff && make -j4 is not very idiomatic Rust. But to get there we need to move from being C with some Rust to Rust with some C.

This is a fabulous plan, but it is aspirational currently