Ghostty is a great piece of software and I’d like to extend it to work better with my workflow. The problem is: I don’t know how Ghostty works. I don’t know how terminals work, how graphics programming works, how macOS and Linux desktop software works, and I don’t even know Zig. In this article, and perhaps others, I will document as much of this process as I can. I hope that this information is useful to others, and useful to my future self.

I will populate a to-do list with questions and actions, and show my working as I figure things out.

• Learn Zig. Ghostty is written in Zig so this will certainly be required.
• Can I get Ghostty to build on my machine (which is an Apple silicon MacBook)?
• What does Ghostty’s own documentation say about its own architecture?
• Are there some simple open GitHub issues that I could feasibly fix?

Learn Zig

Zig’s main website is https://ziglang.org. The Learn page lists not too many resources, so I will:

• Judge which ones will be useful.
• Read them.

Which resources look useful?

Reference documentation is going to be vital. There are sections for Unstable (master) and Latest Stable (0.14.0). The choice is trivial because Ghostty’s flake.nix explicitly specifies Zig 0.14.0.

After opening everything else on the page except for the Relevant videos and blog posts (which seem rather irrelevant to me), here are my picks roughly in reading order:

• Ziglings. Seems like a fun idea. I hope that my C++ experience has given me transferrable knowledge and that exercises would be effective for me.
• Introduction to Zig. At a glance this seems easy to read and navigate.
• Zig Build System. Ghostty uses the Zig build system so this will inevitably be relevant at some point. Worth a skim to know how the build system works and what it can do.
• Zig 0.14.0 Language Reference.
• Zig 0.14.0 Standard Library Documentation.

Read Ziglings

This needs Zig 0.15.0. nix search nixpkgs zig only lists Zig 0.14.0. Someone tried to add a Nix flake to Ziglings, which was rejected but a comment suggests nix shell 'github:mitchellh/zig-overlay#master' as a workaround. Running that command and zig build in a local clone of the repo confirms this.

Time passes…

This was very enjoyable. Noteworthy discoveries:

• const applies to the contents of an array, so an array is not a boxed type.
• A string is an array of bytes; how does that work with multi-byte UTF-8 codepoints? The language reference confirms that “Indexing into a string containing non-ASCII bytes returns individual bytes, whether valid UTF-8 or not.” It also says that Zig source code is UTF-8 and that UTF-8 literals carry their meaning when appearing within a string literal.
• Strings are null-terminated like in C, so wouldn’t "ha " ** 3 be equivalent to [_]u8{'h','a',' ',0} ** 3 or "ha \0ha \0ha "? I suppose the fact that strings are null-terminated is represented in the type so that ** knows not to replicate the null terminator.
• It appears at first glance (and I may be corrected on this) that functions can accept arrays by value, which is not possible in C. In C, code that calls a function passing an array actually passes the address of the array.
• Errors are first-class, and are not the same as exceptions in other languages.
• switch seems is equivalent to a series of if statements checking for equality, which is not quite the same as in C. C switch only works on integers. (I can’t verify this from the language reference).
• It seems inconsistent that you don’t need to use p.*.f to access field f within the referenced struct.