You are browsing as a guest. Sign up (or log in) to start making projects!

Rust Emacs dynamic Module bindings

  • 4 Devlogs
  • 14 Total hours

This is a high level bindings for writing Emacs dynamic modules in Rust. This project is a fork of the [emacs-module-rs](https://github.com/ubolonton/emacs-module-rs) because I need changes for my other project [rag](https://stardance.hackclub.com/projects/27206) and upstream seems to be abandoned.

Open comments for this post

2h 0m 26s logged

I made the test runner work with cargo test and removed all the old autoconf stuff. This makes things easier for other people to work on the project who don’t know how to use autoconf and only know how to use the rust based tools.

0
0
2
Ship #1 Changes requested

# What did you make?

I made a fork of the [emacs-module-rs crate](https://github.com/ubolonton/emacs-module-rs)
because the repository seems to be abandonned, and my prs have been ignored for a
week now and I need changes for my [other stardance project](https://stardance.hackclub.com/projects/27206).

`emacs-module-rs` and my fork is a library for Rust that allows [writing dynamic modules](https://www.gnu.org/software/emacs/manual/html_node/elisp/Writing-Dynamic-Modules.html)
for Emacs (which are shared libraries which are loaded by Emacs to
extend the functionality of the text editor, often for performance
reasons).

The reason that I wanted to change the upstream code was that upstream code has
"bloated" code generation where the library would do things like
[allocate strings at link-time in order to create the name of the LISP function](https://github.com/ubolonton/emacs-module-rs/blob/80b018a768da7bb1a1c346e8ae77e73fe7d35f1a/src/func.rs#L48)
which is inefficient since this information can be computed at compile
time, making the extra allocations (which are fallible and may crash
Emacs) unnecessary.
There are other things that I think the upstream code did wrong and rather than wait for the maintainers who haven't committed anything in 4 months, I decided to fork the project.

After making my other project which is a Emacs dynamic module to using
the binary size of the compiled shared library went down by ~20kb
showing that the crate is unnecessarily bloated.

# What was challenging?

What was challenging was rewriting the build system for the
project. While the crate is a typical Rust project, meaning it uses
cargo for compiling, the test harness needs to use the Emacs' [ert library](https://www.gnu.org/software/emacs/manual/html_node/ert/index.html)
so it needs some sort of build system to compile the modules and run
the tests.

In upstream, they use a [custom cargo subcommand](https://github.com/ubolonton/emacs-module-rs/tree/80b018a768da7bb1a1c346e8ae77e73fe7d35f1a/xtask)
which contains [a lot of dependencies](https://github.com/ubolonton/emacs-module-rs/blob/80b018a768da7bb1a1c346e8ae77e73fe7d35f1a/xtask/Cargo.toml) which slowed compilation in CI runs.

This made me want to use a different build system and I settled on
autoconf without automake so that the configure script would gather
[information about the system](https://github.com/butterfingres/rem/blob/f2aa2836569e74751595a99e30d143c64af093b7/configure.ac#L35)
and configure the build system accordingly.

This was difficult because I had never used autoconf before and I had
to learn this new build system.

# What are you proud of?

I am proud of the fact that I was able to refactor and improve the
emacs-module-rs crate into something better.

# What should people know so they can test your project?

In order to test the project you would need to install an Emacs
version which is at least version 25 and a recent Rust compiler. For a
basic emacs dynamic module you should read [this guide for instructions](https://github.com/butterfingres/rem/blob/master/doc/hello.md).

P.S. the demo image is an image of [my other project](https://stardance.hackclub.com/projects/27206) which now uses this new library.

  • 3 devlogs
  • 12h
Try project → See source code →
Open comments for this post

7h 9m 41s logged

I removed static items from the initialization code. Basically in upstream they want to have good developer experience so they want to have macros that both declare functions and register them into the runtime by running code at dynamic linking time that modifies statics with things like mutexes even though the code will be ran single-threaded at load time. My fork of the project removes those features so that the code is simpler and performant by requiring the user code to register the things they need themself.

0
0
3

Followers

Loading…