My dream terminal emulator

2024-03-13

Today I thought I would talk about what my ideal terminal emulator would look like. But instead of just talking about some cool features that would be nice to have, I would also like to announce that I've started working on one. It will be written in C++, which is the best programming language on planet earth, and throughout this blog post I'm going to talk about the goals of the project.

Infinitely extensible

Most terminal emulators don't allow for enough customization. st is a unicorn in this regard, it allows for a ridiculous amount of customization, because of the suckless philosophy. This is something that I really like about st. But the downside is, in order to properly customize it, you really need to learn C, and then learn their convoluted codebase, which isn't easy to read at all.

My approach would be completely different. I would add a plugin system of some kind, which would allow for any kind of changes you'd want to make to the terminal emulator, and in practically any language you want. But, in addition to this, I would also use Lua for the configuration file. It seems like an obvious choice to me, given that Lua allows one to write real(ish) programs, but at a high level.

The main reason extensibility matters so much, is because if the upstream project doesn't want to add the feature you're after, you're SOL if you can't add it in yourself, and possibly share it with other users.

GPU accelerated

In the age of terminal user interface applications (TUIs), speed matters more than you think. I used to think GPU accelerated drawing was overkill, and yes, for most use cases it is. As soon as you're dealing with modern user interfaces where lots of text is drawn at the same time, often with many escape sequences constantly being read and parsed, you will feel the slowness of software rendered terminal emulators such as xterm, rxvt-unicode and st.

Existing terminals such as Alacritty and Kitty provide GPU acceleration, but to my knowledge this is using OpenGL. I think, with a new project, we can do better than that. Why not use Vulkan instead? In theory, Vulkan should provide better GPU performance. Of course, that's in a perfect world, but I think Vulkan would be able to provide better performance on newer hardware.

As for older hardware, I honestly don't care that much. Excellent performance on modern systems is much more important than supporting a GPU that was already outdated over a decade ago. With that said, I hope to support OpenGL as well, which would allow even the oldest of GPUs to at least run the terminal emulator in some fashion. I would really like to avoid implementing CPU rendering, though.

Also, this is just an idea, but why not implement support for rendering 3D models while we're at it? We're using the GPU, after all.

Great Unicode support

We need great Unicode support, or text support in general. It's 2024, users expect their text to be rendered appropriately. Text should be shaped, and the terminal should have full support for Unicode, provided the appropriate fonts are installed on the system. On top of that, ligatures should also be implemented, as I know a lot of people expect ligatures out of their terminal emulator.

As of now, the terminal that provides the best Unicode support is by far Kitty. It even supports the Unicode emojis that use two glyphs (such as flags, and the new emojis added solely for diversity). In my opinion, that makes Kitty the only terminal emulator that meets my requirements regarding Unicode support, and text in general.

Different text size

This is something I haven't seen any terminal emulators support. Wouldn't it be cool if we could draw text that covered multiple lines? Or, how about smaller text? Or really, text at any position. One use case for this would be a Markdown preview plugin in Neovim, but there are probably a lot of use cases for something like this.

Screw compatibility

Honestly, who cares about compatibility with a terminal from the 20th century? While support for some features are worth preserving (this is a terminal emulator after all), generally we should probably not implement support for features that haven't been used in decades. Why implement old features in a brand new terminal? Especially when some of those design choices actively impact the applications we use today.

For instance, why can't we map Ctrl+Tab? Compatibility. Compatibility is the answer. It's not like this is something that actually matters in practice, however. Maybe the terminal would be unsuitable for some use cases as a result of this, but I believe the user experience would really benefit from this.

Image protocol

There are far too many image protocols right now, and most terminal emulators only support one. I think the Kitty protocol provides the best results, as of now, so I think the Kitty protocol is worth implementing. But, the sixel and w3m protocols should also be possible to implement, through plugins.

But hey, why limit ourselves to just images? Why not videos/animated GIFs too? And why not implement some way to draw primitive graphics (basic shapes) anywhere on the screen? Another idea I have is embedding WebKit or something. This would allow programs to display HTML/CSS/JS elements. But, I'm not sure how to do it in a non-bloaty way, that works well on both X11 and Wayland.

*NIX support

Ideally, I'd want to support Linux, BSD, macOS and any other Unix-like operating systems. Windows I don't care about all that much, but that's mainly because Windows likes to do everything differently.

Unfortunately, supporting macOS means implementing the Metal graphics API, because Apple does not support OpenGL, or even Vulkan for that matter. But, I plan on using the Google Skia library (I've already written abstraction for it) so I don't think this would be an issue, as it implements OpenGL, Vulkan, Metal and even DirectX with minimal changes.

Another important feature however is Wayland support. If we're going to support the latest graphics API, we should also support the latest display server.

Tabs

I don't have a strong need for tabs, to be honest. But I think tabs would be really cool, as it could replace all of those terminal instances you might have running, and wasting space in your tiling window manager.

Oh yeah, that reminds me. Splits. Why not? This would pretty much make tmux useless to me, which would only be a good thing because tmux only seems to make my life harder, thanks to terminfo nonsense.

Graphics library

Like I said, I plan on using the Google Skia library to draw graphics. It seems like the best tool for the job, which is insanely fast graphics, primarily 2D graphics. I don't really have any interest in using something complicated like GTK or QT, as for what I want to accomplish, primitive drawing is pretty much enough. Simple graphics, text and of course shapes is all that I need for this.

Skia is nice because it can handle all of this, and it does so using the GPU, unlike other options such as Cairo, which I used for spmenu. It's also made by Google, which is good because it's not going to run out of funding any time soon, and is the drawing library used by many important programs such as Chromium, Firefox, WebKit (so all of the browser engines), LibreOffice and more. It is slowly replacing other options like Cairo, which is great because it means more programs will run faster.

The alternative is, of course, to manually write a Vulkan backend, along with all code for drawing shapes and of course text. Can this be done? Yes. But considering not even suckless attempted it, instead opting to use libXft, I don't feel like wasting my time writing all of that boilerplate, when it's all a waste of time anyway.

Conclusion

These are some features I want in my terminal emulator. I've started working on a terminal emulator that will (hopefully) support most if not all of these features. I think at the very least I'll be able to write a simple terminal emulator, and if that cannot be done I could in theory just copy paste code from st. Point is, I'm not worried about not being able to finish this project.

That's all I had to say I think. If you have any ideas, feel free to edit this page or comment them below. Have a good rest of your day!

Source