muterm

This is a terminal emulator for X11, distributed under a BSD licence. It has the following features:

It's independent of any toolkit. Just requires the base X11 libraries and the freetype library.
Can be linked statically.
Doesn't need a font from the system. It contains its own font. This makes it independent from linux distributions or font settings etc. You just put this thing somewhere in your $PATH and you're good to go.
When compared to vte-based terminals, it's very fast due its lazy update mechanism. This comes in handy for running programs like GNU configure etc.
It protects users from distractive terminal features such as blinks, bells, multiple fonts etc.
It doesn't allow programs to manipulate the terminal in ways that are distracting. For instance, it will never let a program minimize or automatically maximize the terminal window.
It's configuration-free. If you like it, it's great. If you don't, so sad.
Copy/paste works like a charm. No more weird middle clicking, although that also works.
Multiple tabs.
No terminal colors, but different color schemes for each tab.
Scroll buffer.
Copy and paste keyboard shortcuts.

I wrote it out of frustration with termit. Although it's a very nice terminal emulator, it has some shortcomings.

The first one is the lack of keyboard shortcuts to navigate between tabs. I added some shortcut for it using ctrl-tab, but it's not very productive.

The second one is the inability to change the terminal color settings quickly. Often, I have multiple tabs open and I get confused about which tab does what. I thought about making them different colors so that I can easily see which is the compiler window, which is the debugging window etc.

The third one is a minor issue, but sometimes significant. With VTE derivatives, in order to paste some text, you need to move the mouse pointer on the terminal cursor. This is just inconvenient. With muterm, you can paste no matter where the mouse pointer is.

Despite its colorful appearance, muterm is in fact a monochrome terminal. Everything is rendered in the same color, except for bold/italic text. This has a very good reason. The original terminal colors were designed for a black screen. However, muterm uses multiple tabs with different backgrounds. Now, if I tried to use the original color scheme for all tabs, then some stuff would be almost invisible. The alternative is to design new colormaps for each tab background. However, this defeats the whole purpose of color. If I have to use a shade of yellow instead of red just because the tab in question has a red background, then whatever that red color meant to signal is now handled by the yellow color. So, you can't get any information from the colors because they all look different in each tab.

What's worse, most terminals allow programs to change the colors on the fly. This creates even more problems because one setting done by a program may be completely inappropriate for another program running right after it. Therefore, I won't implement any color shenanigans. I prefer it this way in any case. Trying to chase down color settings for each stupid color-enabled program is a waste of my time. Just thinking of GNU 'ls' with its hideous colors makes me uneasy.

The emulator identifies as an xterm thru the environment variable. This lets programs to find a suitable termcap entry for it. However, it doesn't do the rest of things xterm does such as informing the running program about the window identifier of the terminal emulator or about the xterm version. This lets programs which rely on that information to fail and not try stupid things I don't like.

I covered a lot of xterm escape sequences but there are tons more of it I didn't and there are some I never will. In general, I skipped the following features.

I didn't implement things related to old character set manipulations. All I/O is considered to be in UTF-8, which is quite a safe assumption to make for my purposes.

I didn't implement urxvt/xterm antics which let the program using the terminal interact with the X11 system. These are things like resizing the window, making its title blink etc. All useless and disruptive.

I didn't implement keyboard mapping things because these are much better handled in the X11 system. I might take a second look at this if I need to later.

I didn't implement the terminal bell. I hate that stuff. There is also no blinking cursor or text.

The rest of xterm features I didn't implement are generally very old features that don't seem to be used by modern programs. Things like irrelevant terminal identification strings, pixel graphics, rectangular area operations etc.

There are still things I should implement at some point. I will delay those until I need them. It's just fine for my purposes as it is.

Download

Here is the latest version: muterm-1.8

Added command line switches -f, -h and -s.

The whole thing has been ported to use the gfx library.

It's now independent of the FreeType library. The truetype code in gfx is used instead.

Here is a fork of 1.8. It's a weird little thing, you use the screen of another linux computer as the terminal display. The connection is made via an internet socket. The address of the other computer must be given on the command line.

This is just a checkpoint on the way to my raspberry bluetooth terminal. This link will take you to mutermRL-1.0.

It could be useful as a screen-sharing tool though, if the local program also interpreted the inputs.

Older Version 1.7

Get it from here: muterm-1.7

This package contains a copy of the original font, this will be removed in the next release.

Usage

Run the muterm binary with the name of the program and its arguments. For instance:

  muterm /bin/bash -l

will work. Not specifying a program in this way will cause muterm to try running "/bin/bash", "/bin/sh", etc.

There are no command line switches, bitches.

Keyboard shortcuts are explained within the program itself. Just click "MENU".

Code

The code is quite modular. X11 graphics, tab handling, main program flow and the terminal emulation parts are all separate modules. These can be extracted to build something else or to port it to another platform.

For example, the graphics module interface simply needs a way to show an image on the screen and the ability to get keyboard/mouse input. Similarly, the terminal emulation part only needs to print some characters on a screen and set the cursor position. You could do this in a memory buffer to automate programs, for instance.

In order to compile it, just run 'make'. Some editing may be required to find libraries, there is no 'configure'.

Other than the binary 'muterm', there is nothing to install. Just put it somewhere in your $PATH or something.

The program can also be linked statically. I made it work with the following settings in makefile:

X11LINK=-lXrandr -lXrender -lXext -lX11 -lXau
FTLINK=-lfreetype
FTCOMPILE=-I/usr/include/freetype2
CFLAGS= $(CCWARN) $(FTCOMPILE) $(DEBUG) $(OPTI)
LFLAGS= -static $(FTLINK) $(X11LINK) $(DEBUG) $(EFENCE)  -lpng -lbz2 -lz

The resulting file was about 2 MB.

Road Map

There are some things to do, when I have the inclination. I only implement things when I need them.

There is no way to resize the thing. It's 80x24. I like it this way, but there might be an occasion to have a bigger terminal etc. I have written the whole thing with resizing in mind, it shouldn't be too hard.
Colors and font size can be configured only from the source code. I made choices suitable for my current hardware and preferences, but it would be better to make it configurable at run time. It's just too much work to make the necessary dialogs etc. There is nothing inherent in the program which hinders this.
In other emulators, there is some setting about converting newlines to linefeeds while pasting data from an external source. This is apperantly necessary for pasting things into applications other than text editors, which I never do. I'll do it when I need it.
If the current tab switches from main buffer to alternate buffer while there is a selection going on, then things can go very wrong.
I also didn't test the case where some output is going on in parallel with an unfinished selection. In general, don't do selections while there is something going on and you will be good.
There is a single-file TTF renderer library on the internet. I could use that instead of libfreetype2.
Screen contents can be dumped using the line printer escape codes and possibly some keyboard shortcuts. These should be documented and could be improved. I'm too bored with this thing right now.
I fix the font upon startup. Line drawing characters are drawn with some C code to match the character cell size because the ones in the font leave spaces around. Currently, only single-line characters are implemented. I could do more, such as double-line and thick characters, arrows etc.

Links

Here are some links that were useful while developing this: