Back to the schedule
Previous: Pathing of Least Resistance
Next: Lakota Language and Emacs

A tour of vterm

Gabriele Bozzola (@sbozzolo)

Download compressed .webm video (17.7M)
Download compressed .webm video (10.9M, highly compressed) g View transcript

Download compressed Q&A .webm video (4.1M)
Download compressed Q&A .webm video (3.3M, highly compressed)

Vterm is a fast and fully capable terminal emulator in GNU Emacs built as a dynamic module on top of libvterm. In this talk, I will give an overview of the package. I will discuss the installation and common customizations. I will go into details on some of the most important features, such as directory tracking or message passing. Finally, I will touch upon known incompatibilities and the future directions of the project.

URL: https://github.com/akermu/emacs-libvterm

Questions

Q5: Does/will this work with 'emacs -nw'?

Yes, it does.

Q4: Thats a nice looking prompt, do you have it on a Git repo we could see, or something of that manner? Thanks, I use Bash right now so I didn't know it was the default on the others.

It is not the default, but it is available easily with oh-my-zsh or similar on fish. I think the prompt is this: https://github.com/sindresorhus/pure

Q3: Is there a plan to avoid the initial compilation step?

Not any time soon. You will have to compile vterm the first time you start it.

Q2: What are differences between Eshell and vterm?

Performance. vterm is like xterm but in Emacs, Eshell is like Bash but in Emacs.

https://github.com/akermu/emacs-libvterm#given-that-eshell-shell-and-ansi-term-are-emacs-built-in-why-should-i-use-vterm

Q1: Could you put your testing scripts up somewhere?

Notes

https://github.com/akermu/emacs-libvterm

Transcript

Hello and welcome to this talk. The title of this talk is a tour of vterm, a fast and fully featured terminal emulator inside GNU Emacs. So let's try to understand what we mean with &quot ;fast and fully featured.&quot ; To do that we'll compare vterm with the packages which are built in Emacs, mainly, term. So let's jump into the vterm. So this is a vterm buffer and this is a ansi-term buffer.

[00:00:29.440] What I'm going to do now is first I'm going to prove to you what we mean by fast. To do that, let me open a large file display on screen-- a large file, this is about one megabyte of data-- and let me time that. It takes about 0.6 seconds with vterm. Let's do the same with with ansi-term. Well, we already see the difference.

[00:00:51.520] So I will use this time to tell you what's different, and what is vterm exactly. vterm is a terminal emulator built on top of an external library. The library is called libvterm, and is the same library used by Newton for their own terminal emulator. It's a C library, and this is what gives us a lot of good features. First, the speed. Time spent here, 0.6, is essentially the time that it takes to: 1. convert the Emacs representation of text into the vterm representation of what is a string, and 2., into actually displaying that, and that can take time if there's fontification involved. So these are the 0.6 seconds there. As we say, in ansi-term, that's much more time. It's much slower. So the terminal will feel much snappier, much faster.

[00:01:42.880] But that's not the main benefit or the only benefit of using this external library vterm. The second big benefit is that vterm has support for all the escape codes that xterm has support for, so vterm is essentially as running xterm inside an Emacs buffer. So let's see that. For example, let's start by looking at the support for colors. We have support for all the colors out of the box. We don't have to do anything. And if we did the same here, well, we have only 20 colors. There's a way to get all the colors, but it's much more involved.

[00:02:19.680] But this is not where vterm shines. We can run all the commands that we want. htop, ncdu, everything runs here. Also this title, it's a fairly complicated manipulation of the window and it will not work here. It just doesn't work actually. Now the terminal is probably messed up. Yes. So using this external library removes the burden from the developers of having to implement support for all the escape codes. We just use those.

[00:02:55.360] So in many ways, running vterm is running xterm inside Emacs, but it's better than that because, since this is an Emacs buffer, we can enjoy a lot of features from Emacs as well as a tighter integration with Emacs itself. For example, as you see here, the title of my buffer is from the directory I'm in. So let's go to my tmp. The title will change. So there's information being exchanged between vterm and Emacs. And of course, the title is not the only place where information is exchanged. I can find a file and I will be in the directory where my terminal is. This feature is also available in ansi-term, and it works also on vterm, and it follows me. So if I go to tmp, I'll get the tmp. If I ssh to a remote server, it will work also on remote servers as well, which is a very nice way to edit files remotely while we're working on a shell.

[00:03:55.600] And second, while vterm is not an Elisp interpreter like eshell, what we can do is we can still run Emacs functions. So for example... that requires some configuration. vterm command (message "hi") as you see there's a "hi" here. So what I'm doing is I'm executing the Elisp function hi. I can drop that and turn it around, hash function to run Elisp functions. Or another one, find-file, same. We call this feature "message passing," and it requires some configuration on the Emacs side as well as in the shell side.

[00:04:32.000] It's important to stress what's the nature of vterm. For instance, every time I'm sending a key binding, it's not immediately clear if my intention is to send it to the shell or to Emacs. So vterm implements some reasonable defaults, but at the moment it's mainly packaged to display characters on a screen. So for example, if you're using evil, the editing commands in evil will not work immediately. There's some work to be done and integration can be improved on that side,

[00:04:58.161] but sometimes we really want this to behave exactly like a Emacs buffer. We want to be able to search. If I try to get it to search, it will not work. I will send it to the shell. So to do that, we enabled vterm copy mode. As you see, copy mode, and now this buffer is essentially a fundamental buffer. I can move around. I can search. So it must have... I can do everything I want. And there are additional features. For example, I can jump around all the prompts. I find this extremely useful, because I can copy updates from my programs. What I always have to do is I have to Google some errors. So what I do is I select that and I have my keybinding in Emacs conf, and I'm Googling what I have to Google. So this is very nice and if I... now that I have selected something, if I just press return, I will go back to my normal editing mode with the text copied, so I can paste it back. So it's a quick way to interact with copy and interact with the output of a buffer.

[00:06:05.841] So finally, let's discuss how to actually use vterm. Let's circle back, let's go, and let's look at the GitHub repo where development is happening. vterm is available in MELPA, but since it's leveraging the power of an external module, you must have Emacs compiled with support for modules, and many distros like Ubuntu, Debian, that's not there. So you have to get Emacs with support for modules: compiling or getting images somewhere else. And also, the first time you are going to use this, which works only on Mac or GNU Linux systems, Emacs will try to find and compile this module, so it's important. This requirement is important. If you're using Windows, well, it's not available and will not work.

[00:06:49.199] So to conclude, I want to just advertise this page. If you have problems, look at the issues and open an issue in case. We'll try to help you. We are very excited about vterm, and I think it's a transformative terminal experience inside GNU Emacs.

Sunday, Nov 29 2020, ~ 2:45 PM - 2:55 PM EST
Sunday, Nov 29 2020, ~11:45 AM - 11:55 AM PST
Sunday, Nov 29 2020, ~ 7:45 PM - 7:55 PM UTC
Sunday, Nov 29 2020, ~ 8:45 PM - 8:55 PM CET
Monday, Nov 30 2020, ~ 3:45 AM - 3:55 AM +08

Back to the schedule
Previous: Pathing of Least Resistance
Next: Lakota Language and Emacs