Zterm terminal emulator

I’ve had this project going for a fairly long time. There had been a thread about it on the previous Zig forum. I’m reposting it because I’d like to do a release again soon, and I would like to have the program translated into other languages when I do.

Main repo on codeberg
Github mirror

Zterm is a terminal emulator for Linux using vte and gtk3. It has a nice simple interface but supports some cool options like split tabs and gradient backgrounds. It was my first large project in Zig and is actually my daily driver.


I tried to build it, but compilation has failed:

@mono:~/zterm$ /opt/zig-0.10/zig build
/home/zed/zterm/build.zig:4:22: error: unable to load '/home/zed/zterm/deps.zig': FileNotFound
const deps = @import("deps.zig");

Did I do something wrong?

You might have to run zigmod fetch to rebuild deps.zig and grab the dependencies.

Thanks, it works now.
It seemed to me something is wrong with color palette - I see green in places where I see yellow in other terms.

I’ll look over that code again, it has been a while.

Can you give me more context for what you mean by this?

The pallet itself seems to be correct, i.e I see green/light-green in the 3rd (counting from 1) column of the pallet and brown/yellow in the 4th one, as in other terminal emulators. But in some applcations (mc, mcedit) yellow seems to be replaced by light-green in zterm.

  • mc - directory header (i.e. words ‘name’, ‘size’, ‘modify time’) are light-green but should be yellow
  • mcedit syntax highlighting - zigs keywords should be yellow but in zterm they are light-green.
YELLOW='\033[1;33m'; echo -e "${YELLOW} text"

is ok, text is yellow, maybe this is specific to mc/mcedit.

mcedit in zt, pub const is light-green:
mcedit in xfce-terminal, pub const is yellow as it should be:

Ok, that’s weird. I also checked using just ansi escape sequences and got the correct behavior, which is why I asked for more context to begin with.

Am issue that I have with the VTE api is that the colors are changed by paying a variable length array (8, 16, or 256 members of memory serves, zt uses 16) so the colors have to be passed in the correct order in the array. It’s kinda dumb, because even C has enums. Anyway, I thought that I had messed it up at first. But I’m off on a tangent, sorry.

I’ll look at the xfce4 terminal source code and compare how they’re handling it with how I’m doing it in Zterm. And since now I know it’s showing up in mc/mcedit I’ll install it for testing.

I also checked this in mate-terminal and xterm, syntax highlighting in mcedit is as needed.
xfce-terminal pic was just the vivid example.


$ zig-out/bin/zt 
thread 7656 panic: reached unreachable code
/opt/zig-current/lib/std/debug.zig:278:14: 0x259eda in assert (zt)
    if (!ok) unreachable; // assertion failure
/opt/zig-current/lib/std/fs.zig:2674:27: 0x2e496f in openDirAbsolute (zt)
/home/zed/zterm/src/config.zig:41:27: 0x2c9375 in getConfigDirHandle (zt)
    if (fs.openDirAbsolute(dir, .{})) |d| {
/home/zed/zterm/src/config.zig:372:31: 0x26a903 in fromFile (zt)
        if (getConfigDirHandle(dir)) |dir_fd| {
/home/zed/zterm/src/gui.zig:386:46: 0x258506 in activate (zt)
    conf = if (config.Config.fromFile(options.config_dir)) |cfg| cfg else config.Config.default();

for the moment I do not know how I managed to triiger this…

aha! I ran zt (from other term), then I switched to (pseudo)-text console (I mean pressed Ctrl-Alt-F1), logged in, then tried to run zt :), it silently exited, switched back to graphic (Alt-F7) and oops, zt crashed.

That’s likely from what is a known issue for the moment. The GtkApplication api ensures that only one instance of the application is running at a time, even if that instance has multiple windows. Unfortunately, when I was first working on the program I took a bit of a shortcut to keep track of open terminals and tabs, that being a HashMap as a global variable (I’m not proud). Anyway, until that code sees a fairly significant refactor there is no way to have more than one window open at a time.

The actual, correct way to implement this sort of thing in a robust way, would be to use a subclass of GtkApplicationWindow that internally keeps a reference to that information, which I have done using Gtk+ in other languages. That’s something that unfortunately my homegrown bindings for Zig don’t know how to do yet.

The actual error message that you got, now that’s puzzling to me. I suspect there’s more going on that might point to a bug in Zig itself, but I’m at a loss to see it.