@keyboardspam

# 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.

This project is a feed reader for emacs that focuses on performance.

The feed reader that I used before this is [elfeed](https://github.com/emacs-elfeed/elfeed) so I will be comparing this with that.

QOL Improvements (over elfeed)

1. Memory usage
The elfeed implementation does a bunch of things that hog memory. For one, the database is held entirely in memory. Rag uses a sqlite database to consume less memory. Another thing is that the xml data is parsed into an AST before it gets processed by the parsers which means that you have both the original XML text and an AST which is duplicated work. To fix this, in rag it uses a xml streaming library (quick-xml) to process xml without an AST.

2. Performance
The biggest focus of this is in performance. One of the things that is improved over elfeed is that the elfeed buffer gets redrawn after every update by erasing the buffer and then redrawing everything which is very inefficient. This consumes a lot of time when elfeed finishes parsing feeds now that the updates are incremental and lazy, we are already multitudes faster than elfeed. There are more optimizations such as that are implemented using arena allocators to reuse allocations, or using references to avoid copying data.

The reason that I need my feed reader (or anything else I use in Emacs) to be very fast because on Linux (I use an Arch derivative btw) I use EXWM as my window manager so whenever ELISP code blocks, I cannot use my computer to do anything else (like remembering to use Emacs as a text editor). As a result I want my feed reader to be as fast as possible.

3. Reliability
One of the issues that I have with elfeed is a bug (that I haven't reported because idk how to describe or reproduce, I also don't have any screenshots) where after the elfeed database gets large enough with entries, the description of entries ends up incorrect where it cuts off halfway or it shows you the description of the wrong entry. I suspect that this has something to do with the fact that the database they use is a custom one implemented in ELISP (before Emacs got sqlite support) so by making a feed reader that uses sqlite which is very battle tested, in my limited experience so far, the database is more reliable here than in elfeed.