Open Mobile Menu Close Mobile Menu

Compiling Emacs with support for libvterm

If you’re using the Emacs version that you installed using apt, snap, homebrew or similar, you might be missing the modules needed to use vterm as your terminal emulator. The obvious question is what is vterm, and why you would want it in your Emacs?

The description of the libvterm package that is the core of vterm says:

An abstract C99 library which implements a DEC VT100/VT220/VT320 or xterm-like terminal emulator. It doesn’t use any particular graphics toolkit or output system, instead it invokes callback function pointers that its embedding program should provide it to draw on its behalf. It avoids calling malloc() during normal running state, allowing it to be used in embedded kernel situations.

But we want a plain English explanation, which is: it’s a really performant terminal emulator, that is capable of running everything you’d expect - and it’s what NeoVim uses for its terminal mode.

The main reason to use vterm instead of shell, term, ansi-term, or other terminal modes in Emacs is performance. It’s immediately obvious how much faster it is than the other implementations, in my tests rendering text was up to to two orders of magnitude faster. It also seems to handle bigger outputs and scrollback much better.

So how do we use it? To do that, we need to install emacs-libvterm package: https://github.com/akermu/emacs-libvterm

Here’s how you can compile Emacs to include the modules required to use the package:

wget https://ftpmirror.gnu.org/emacs/emacs-26.3.tar.gz
tar xf ~/Downloads/emacs-26.3.tar.gz
cd ~/Downloads/emacs-26.3
./autogen.sh
./configure --with-modules
make -j`nproc --ignore 2`

# optional, if you want to install the new compiled version globally
sudo make install

The above code is pretty straight-forward: it downloads and extracts Emacs 26.3, prepares it for compilation, and then finally compiles it.

One part worth elaborating about is the compilation step: using the -j flag enables us to specify how many cores you want to use for running the command, and running nproc returns the total number of threads you have on your machine (for example, the laptop I wrote this post on has 6 cores and 12 threads). Telling nproc to ignore 2 threads makes sure that when you’re compiling, make doesn’t use all of your CPU resources and render your machine practically unusable until it finishes.

If you enjoyed this article, subscribe to Miloš's Monthly Musings to get more articles like it in the future: