Libghostty 1.0 Made the Terminal a Library. JetBrains Picked It for IDEs With 12.5M Users (2026)

JetBrains retired its own terminal emulator in October. Starting with the 2026.3 builds, the terminal inside JetBrains IDEs hands every byte it receives to a C library that Mitchell Hashimoto, the HashiCorp co-founder, pulled out of the Ghostty terminal app. On November 6, that library reached 1.0.

libghostty-vt, the MIT-licensed C terminal-emulation library extracted from Ghostty, reached version 1.0 on November 6, 2026. Its creator, Mitchell Hashimoto, now promises a stable C ABI under semantic versioning. It parses the bytes a program writes and keeps the screen, cursor and scrollback. Rendering, windows, fonts and the pty are still yours to build.

Last updated: November 7, 2026. Figures link to their sources with the date they were published or read.

You're reading this on a directory's blog. SaaSCity is a gamified startup directory with a live city map and human editorial review, so we have a stake in developer tools getting built and found.

Key takeaways

• libghostty-vt 1.0, released November 6, 2026, freezes the C ABI of Ghostty's terminal core under semantic versioning. It is MIT licensed, with no copyleft in its dependencies.
• JetBrains made it the default terminal engine in its 2026.3 IDE builds, replacing JediTerm.
• Coder's ghostty-web puts the WebAssembly build behind an xterm.js-compatible API in roughly 400 KB.
• Building from source needs Zig 0.17.x, so plan the toolchain and a fallback.

What is libghostty-vt, and what does version 1.0 change?

libghostty-vt is the part of Ghostty that understands terminals, packaged as a C library any program can link, and version 1.0 turns its C ABI into a promise. The documentation states the contract in one line: you give it the bytes a program writes, and it exposes the state of the terminal, meaning the screen, the cursor and the scrollback. In libghostty is coming, published September 22, 2025, Hashimoto wrote that terminal emulation "appears simple on the surface but is riddled with unexpected complexities and edge cases."

The "-vt" suffix is there because more libraries are planned: input handling, a GPU renderer that draws into an OpenGL or Metal surface you supply, and GTK widgets and Swift frameworks for a whole terminal view. The Ghostty README says the project is "breaking libghostty down into separate libraries, starting with libghostty-vt." Only that first library is 1.0.

Hashimoto's release post declares the library and its C ABI stable. The pull request that prepared the release, merged on November 6, calls itself "mostly a mechanical change," skips version 0.1.0 so the first tag is vt-1.0.0, and notes that "the ABI goldens are untouched." The library also got its own release cycle, separate from the Ghostty app, with its own tarballs, a SONAME, pkg-config files and a CMake package.

On November 7, 2026, the ghostty-org/ghostty repository showed about 63.8k stars and 18,735 commits under an MIT license. Its README says Ghostty and Alacritty "are usually within a few percentage points of each other on various benchmarks" and that both are "something like 100x faster than Terminal.app and iTerm," without publishing a method.

Which products use libghostty-vt, and what does the 12.5 million figure mean?

JetBrains IDEs, Vercel's Turborepo, devenv, OrbStack, the Emacs package Ghostel and KDE's Kwi experiment already ran libghostty-vt before the 1.0 tag, and Neovim has an approved pull request to join them. Hashimoto's post says, "More people today use a terminal powered by libghostty than use Ghostty the application, by a very large multiple." The docs estimate "tens of millions of people daily," while noting the project does no tracking.

JetBrains is the largest adopter. In The Terminal in JetBrains IDEs Now Runs on libghostty, published October 27, 2026, Ekaterina Valeeva writes that libghostty replaces JediTerm, "the terminal emulator we relied on for many years," and "takes over parsing and terminal state in our IDEs, while the IDE still handles rendering, and higher-level features and integrations."

The post says the new engine handles almost 50 control sequences that JediTerm ignored or misread. With the Kitty keyboard protocol, Shift+Enter starts a new line in a prompt instead of sending a half-written message, and theme-change notifications now reach Neovim, tmux and OpenCode. JetBrains says the engine stays on by default from the 2026.3 early-access builds through the stable release.

JetBrains' Annual Highlights 2026 reports 12.5M+ recurring active users, defined as unique users who engage with its products regularly over a calendar year. The chart puts 2025 at 12.5 million, up from 5.9 million in 2019. That's the audience the new terminal reaches as 2026.3 rolls out. It doesn't tell you how many people have opened the terminal, which nobody measures.

A pull request by noib3, opened May 13, 2026, replaces libvterm with libghostty-vt in Neovim's built-in terminal. As of November 7 it is approved and still open, waiting on a Zig 0.17 upgrade and a tagged release; maintainer clason wrote on October 27, "We want to track releases, not HEAD." Once merged, it closes issue #4997, ":terminal text clipped after resize," opened on July 1, 2016, because, as the PR puts it, "we now have proper reflowing of lines in the scrollback region." On November 7 the PR showed 2,576 lines added and 13,077 removed across 83 files.

On November 1, 2026, KDE developer Eike Hein introduced Kwi, a Qt terminal built on libghostty-vt with its own GPU renderer and a Kirigami interface. Hein calls it "an experiment and a proposal" and hasn't tagged a v0.1.0 yet. Hein's own benchmarks put it 3x to 35x faster than Konsole, depending on the test. The post also expected libghostty-vt to make its stable 1.0 promise "at some point in the next 4-6 months." It shipped five days later.

Project	What libghostty-vt does there	Status	Source
JetBrains IDEs	Parsing and terminal state; the IDE renders	Default in 2026.3 builds	JetBrains blog, Oct 27, 2026
Neovim	Replaces libvterm in :terminal	Approved PR, not merged	PR #39773, opened May 13, 2026
Vercel Turborepo	Terminal state behind the task-output panes, replacing a vendored vt100 crate	Merged	PR #13135, Jun 25, 2026
devenv 2.1	One VT parser for every shell, including zsh, fish and nushell	Released	devenv blog, May 7, 2026
Bombadil	Reads screen state while fuzzing TUI programs	Merged to main	wickstrom.tech, Apr 30, 2026
KDE Kwi	Terminal core under a Qt and Kirigami UI	Experimental, untagged	KDE Blogs, Nov 1, 2026
Ghostel	Terminal emulator inside Emacs	On MELPA	dakra/ghostel
ghostty-web	WASM build behind an xterm.js-compatible API	On npm	coder/ghostty-web
OrbStack, cmux, herdr	Embedded in commercial and open-source terminal tools	Shipping	Hashimoto, Nov 6, 2026

The Turborepo PR gives the plainest reason for adopting the library: "Ghostty's VT library is actively maintained, supports modern terminal features, and is the same engine powering the Ghostty terminal." Oskar Wickström's Bombadil terminal experiment, dated April 30, 2026 and credited by Hashimoto to Antithesis, fed random input to TUI programs and read back cell contents and styles through libghostty-vt at "at least 300 states per second." It found four seemingly real bugs: a freeze in vitetris, two in btop and a segfault in rlwrap. Hashimoto also counts community bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java and more, and the awesome-libghostty list "tracks well over a hundred projects."

Is libghostty production-ready, and what does the ABI promise actually cover?

libghostty-vt 1.0 is ready for production as a terminal-state layer: JetBrains ships it as the default engine, and every change to its C ABI is checked in CI. Hashimoto treats the ABI as the point of the release: "I believe the hallmark of a high-quality and enduring C library is ABI stability." Per the release post, the 1.0 design works like this:

• Every object is an opaque handle, so internal layouts can change without breaking your build.
• Hundreds of values go through a few enum-keyed getters and setters, so new values need no new symbols.
• A program built with newer headers but linked to an older library gets GHOSTTY_UNSUPPORTED instead of a crash.
• The few non-opaque structs carry their own size or reserved padding, so fields can be added later.
• Enums are pinned to int on every compiler, "as much as the C standard allows."
• CI checks every change with libabigail against a committed baseline on Linux, and against golden type manifests on macOS and WebAssembly.
• On ELF platforms every exported symbol is versioned, so the loader rejects a mismatched library by name.

The PACKAGING-LIBGHOSTTY.md guide covers distribution. Each release ships a minisign-signed source tarball and a dependencies tarball in Zig's cache layout, so distributions can build offline. The SONAME carries only the major version, libghostty-vt.so.1 for every 1.x release, and the build honours --prefix, DESTDIR and lib64, which is what Debian, Homebrew and enterprise build farms expect.

The compiled-in dependencies are simdutf and Google Highway for SIMD, a compact Unicode table for grapheme data and Wuffs for Kitty graphics images, each listed with version, SPDX license and hash. Hashimoto writes that "there is no copyleft code anywhere in the dependency tree," which matters to any team whose lawyers have blocked an LGPL dependency in a statically linked product.

CI status	Platforms (from the 1.0 post)
Tested (full unit tests and every example)	Linux glibc and musl (x86_64, aarch64); macOS 13+ (x86_64, aarch64); iOS 13+ (aarch64); FreeBSD (x86_64, aarch64); Windows (x86_64); Android (aarch64, x86_64, arm); WebAssembly wasm32 freestanding
Built, not test-run ("all have known users")	Bare metal riscv32 and thumb; WASI wasm32; Windows arm64; illumos x86_64; 32-bit x86

The default build links libc for its SIMD paths and malloc-based allocator. With SIMD off it builds freestanding, which is how it runs on bare-metal RISC-V and ARM. The small WebAssembly build stays under a megabyte with every feature enabled, and a read-only viewer build roughly halves it. The library creates no threads and allocates only through an allocator you can replace. Hashimoto's stress test ran 10,000 active terminals, each with a live shell producing output, on a Linux server with 4 cores and 8 GB of RAM. The test used dash, because bash took far more memory than libghostty-vt itself and wouldn't fit.

Libghostty vs xterm.js vs libvterm vs VTE: which terminal library should you use in 2026?

In 2026, use libghostty-vt for native apps and servers, xterm.js or ghostty-web in the browser, libvterm when you want a tiny C dependency you already know, and VTE only inside a GTK app. libghostty-vt is the only option here that covers Windows, mobile, WebAssembly and bare metal with one ABI-checked core. Each row below comes from the project's own pages:

	libghostty-vt 1.0	ghostty-web	xterm.js	libvterm	VTE
What it is	C library for terminal state, written in Zig	libghostty WASM build with an xterm.js-compatible API	Browser terminal component	"Abstract" C99 terminal library	GTK "Virtual Terminal library"
License	MIT, no copyleft in dependencies	MIT	MIT	MIT	LGPL-3.0-or-later
Runs on	Linux, macOS, iOS, Android, FreeBSD, Windows, WebAssembly, bare metal	Browsers	Browsers and Electron	Anywhere C99 builds	GTK desktops
Draws the screen	No	Yes, in the browser	Yes, with an optional WebGL addon	No, it calls your callbacks	Yes, as a GTK widget
You still build	Renderer, pty, input wiring, UI	Backend and pty	Backend and pty (node-pty)	Renderer, pty, input	Your app around the widget
Known users	JetBrains IDEs 2026.3, Turborepo, devenv, OrbStack	Coder's Mux, where it started	VS Code, Tabby, Hyper	Neovim today, Qt Creator 0.3.3	GTK terminal apps

If your browser terminal runs on xterm.js, there's no need to rush. xterm.js is MIT licensed, has about 21.3k stars, names VS Code, Tabby and Hyper among its users, and connects to processes through something like node-pty. ghostty-web is the gradual way off it. Coder first built it for its Mux app. It ships a WASM bundle of roughly 400 KB, and the README's migration advice is to change your import from @xterm/xterm to ghostty-web. It "aims to be API-compatible," so test your addons first.

libvterm calls itself "an abstract library implementation of a VT220/xterm/ECMA-48 terminal emulator." Paul Evans wrote it in C99, Launchpad lists it as MIT, and Qt Creator ships version 0.3.3 per Qt's attribution page. It's small and it works, but its project page was last modified in January 2023, and Neovim, its best-known user, is preparing to leave. VTE suits a GTK app that wants a finished widget, and Arch Linux's vte4 package lists it as LGPL-3.0-or-later.

How to embed libghostty-vt in your own product

Embedding libghostty-vt takes six steps: get the release, build and link it, feed it bytes, read the state back, connect your own renderer, pty and input, then trim features and keep a fallback.

1. Get the release and verify it. Download the libghostty-vt 1.0.0 source and dependency tarballs from release.files.ghostty.org and check them against SHA256SUMS and the minisign signature.
2. Build and link the library you need. Build with Zig 0.17 and zig build -Doptimize=ReleaseFast, then link the shared or static library through pkg-config or CMake, or build the wasm32 module for a browser.
3. Create a terminal and feed it bytes. Create a terminal with ghostty_terminal_new at your grid size and pass every byte from your pty, socket or recording to ghostty_terminal_vt_write.
4. Read the screen state back. Use the formatter to get the screen as text, or the render-state API to walk dirty rows, cells, styles and the cursor when you draw.
5. Wire up your renderer, pty and input. Draw the cells with your own renderer, run the child process on your own pty, and turn key and mouse events into bytes with the library's encoders before writing them to the pty.
6. Ship only the features you need, with a fallback. Leave out optional parts with -Dvt-features if size matters, keep SIMD on for native builds, handle GHOSTTY_UNSUPPORTED results, and keep your old engine behind a switch for the first releases.

Steps 1 and 2: the packaging guide lists the source tarball, the -deps tarball, their .minisig signatures and a signed SHA256SUMS under release.files.ghostty.org/libghostty-vt/1.0.0/. Per the guide, "libghostty-vt 1.0.0 requires Zig 0.17.0"; any 0.17.x works, while 0.16 and 0.18 don't. From a Git checkout you add -Demit-lib-vt, or zig build produces the Ghostty app instead.

# Inside the unpacked libghostty-vt-1.0.0 source tarball
DESTDIR=/tmp/pkg zig build \
  --prefix /usr \
  --system ../libghostty-vt-1.0.0-deps \
  -Doptimize=ReleaseFast \
  -Dcpu=baseline

# Link a C program against it
cc hello.c $(pkg-config --cflags --libs libghostty-vt) -o hello

In CMake, use find_package(ghostty-vt 1.0 REQUIRED) and the ghostty-vt::ghostty-vt target. For a browser, build with -Dtarget=wasm32-freestanding -Doptimize=ReleaseSmall and read the ghostty_type_json export for enum values, or skip the build and use ghostty-web from npm.

Steps 3 and 4, from the docs front page:

#include <stdio.h>
#include <string.h>
#include <ghostty/vt.h>

int main(void) {
    GhosttyTerminal terminal;
    ghostty_terminal_new(NULL, &terminal, 80, 24);   // NULL = default allocator

    const char *text = "Hello, \x1b[1;32mworld\x1b[0m!\r\n";
    ghostty_terminal_vt_write(terminal, (const uint8_t *)text, strlen(text));

    GhosttyFormatter formatter;
    ghostty_formatter_terminal_new(NULL, &formatter, terminal);
    uint8_t *buf = NULL;
    size_t len = 0;
    ghostty_formatter_format_alloc(formatter, NULL, &buf, &len);
    fwrite(buf, 1, len, stdout);                     // prints "Hello, world!"

    ghostty_free(NULL, buf, len);
    ghostty_formatter_free(formatter);
    ghostty_terminal_free(terminal);
    return 0;
}

The bytes can come from a pty, a WebSocket or a recording. For drawing, the c-vt-render program in Ghostty's example folder calls ghostty_render_state_update for a snapshot, walks the changed rows with ghostty_render_state_row_iterator_next_dirty, reads each cell's codepoints and style, and calls ghostty_render_state_clean after the frame is drawn.

Step 5 is your own code, and Ghostling shows how much of it there is. The official demo is a complete terminal in a single C file, using Raylib for the window and drawing, and Hashimoto puts it at about 1,500 lines of C. Its README says Ghostling "isn't meant to be a full featured, daily use terminal," and its list of what the library will never give you is the clearest scoping document in the project.

For input, the c-vt-encode-key example creates an encoder with ghostty_key_encoder_new, enables the Kitty keyboard flags and calls ghostty_key_encoder_encode to get the bytes for a Ctrl+C press. Mouse and focus events have encoders of their own. The pty is whatever your stack already uses: Bombadil pairs the library with Rust's portable-pty crate, and Kwi uses KPty from KDE Frameworks.

Step 6: -Dvt-features drops optional parts, and functions you left out return GHOSTTY_UNSUPPORTED, so check for that result. The guide's read-only viewer example is -Dvt-features=-all,+render-state, and it warns that -Dsimd=false "makes the library much slower." For the fallback, copy JetBrains. A registry key, terminal.use.ghostty.emulator, switches its terminal back to JediTerm, and bug reports go to issue IJPL-218849.

Where does terminal emulation show up in SaaS products, and what does building on it cost?

Terminal emulation shows up wherever a customer reads the output of a process. Hashimoto's 2025 post named JetBrains on JediTerm, VS Code on xterm.js and Zed on Alacritty, plus GitHub Actions logs that parse "simple color sequences" and Vercel and Render build logs that handle line clearing, redrawing and colors.

In products shipping in 2026, that means cloud IDEs and notebooks (the xterm.js README lists Eclipse Che, JupyterLab, Azure Cloud Shell and Replit), consoles for per-customer sandboxes like the ones in our piece on AWS Lambda MicroVMs for SaaS sandboxes, and deploy logs and CI pages on GitHub or a federated forge like Tangled. It also covers terminal-based coding tools, where JetBrains names Claude Code, Codex, OpenCode and Pi. The libghostty-vt docs add session recording, test harnesses for TUI apps, and automation that reads what a TUI is showing.

That last group matters most. A CLI that redraws progress bars with carriage returns and paints full-screen interfaces produces stdout that no regex parses reliably. A terminal-state library gives you the screen a person would have seen, cell by cell, ready to diff, index, test or pass to another program.

A homegrown emulator costs more than teams expect. JetBrains maintained JediTerm for years and still had almost 50 control sequences wrong. Neovim's resize bug stayed open for a decade, and Turborepo carried a vendored vt100 crate until June. Hashimoto's 2025 post says "implementing any form of terminal emulation is a waste of time for most developers," and that it "is not the core business of JetBrains, Visual Studio Code, GitHub, Vercel, Render, etc."

Embedding has its own bill: Zig in your build chain at an exact minor version, a renderer you write yourself (Ghostling's roughly 1,500 lines of C is about the floor), and 400 KB to 1 MB of WASM on browser pages. That's still cheaper than an emulator that needs fixing every time a popular tool adopts a new escape sequence.

What does libghostty 1.0 not cover yet?

1.0 covers the VT core only. The renderer, windowing, fonts and pty are yours, and the planned rendering and widget libraries have no release. Hashimoto says the next phase focuses "on stability while implementing as many terminal protocols as exist."

The toolchain causes the most friction. Neovim's switch waits on its Zig 0.17 upgrade, and Turborepo's PR made Zig 0.15.2 or newer a requirement for building turbo. Adopters also move in stages: the IntelliJ IDEA 2026.3 documentation says SSH sessions still use the Classic engine, which is built on JediTerm. On Windows, CI tests only x86_64.

In the Hacker News thread for Ghostty 1.4 in late October, one commenter wrote, "we should just have a gold standard library for this," and a KDE contributor said they had "been working on a new frontend built on libghostty-vt." In the same thread Hashimoto planned to tag 1.0 "in the next few months," and the tag came within two weeks. Keep a fallback switch for a release or two anyway.

The founder lesson: extract the core, support it like a product

Ghostty's library reached more people than the app because companies could take the core without the app. JetBrains kept its terminal UI and swapped the engine underneath, and Turborepo kept its ratatui interface while replacing the parser behind its panes.

Find the part of your product that other teams keep rebuilding badly, such as a parser or a sync protocol, and license it so a legal review takes a day. Then treat the dull parts as product work, the way Hashimoto shipped ABI checks, symbol versions, signed tarballs and offline builds with 1.0. Hashimoto's argument fits any shared dependency: "Every bug any libghostty-vt embedder reports makes everyone else in the ecosystem better."

If you're building on libghostty, say a web terminal, a session recorder or a TUI test harness, you still have to get it in front of people. Our list of directories for developer tools covers where developers find new tools, and SaaSCity is one of them. A Basic listing is $19.99 one-time, reviewed by hand and live within 24 hours, with a dofollow backlink and a building on the city map. Premium at $39.99 adds a 3000+ word launch review on this blog with five links to your site, published within three days.

Questions people ask about libghostty

What is libghostty-vt, and what does version 1.0 change?

libghostty-vt is a portable, MIT-licensed C library for terminal emulation that Mitchell Hashimoto extracted from the Ghostty terminal. It takes the bytes a program writes and keeps the terminal state: screen, cursor, scrollback and styles. It does not draw, open windows or run a pty. Version 1.0, released on November 6, 2026, makes the C ABI stable under semantic versioning and gives the library its own releases, signed tarballs, a SONAME, pkg-config files and a CMake package.

Is libghostty production-ready in 2026?

For terminal state, yes, with caveats. JetBrains made a libghostty-based engine the default terminal in its 2026.3 IDE builds, Vercel's Turborepo merged it on June 25, 2026, and libabigail checks every ABI change in CI. The caveats: only libghostty-vt is 1.0, you still write the renderer and the pty handling, building from source needs Zig 0.17, and JetBrains kept a registry switch back to JediTerm.

What does the libghostty ABI stability promise cover?

It covers the C ABI of libghostty-vt across 1.x releases. Objects are opaque handles, most values go through enum-keyed getters and setters so new ones need no new symbols, and newer headers linked to an older library get GHOSTTY_UNSUPPORTED instead of a crash. CI checks changes with libabigail on Linux and golden type manifests on macOS and WebAssembly, ELF symbols are versioned, and the SONAME stays libghostty-vt.so.1 for every 1.x release.

Should I use libghostty or xterm.js for a web terminal?

If xterm.js already works for you, there is no rush. If complex scripts, newer escape sequences or one engine shared with your native apps matter, try Coder's ghostty-web. It wraps libghostty's WebAssembly build in an xterm.js-compatible API, ships a WASM bundle of roughly 400 KB, and its README says migration starts by changing the import from @xterm/xterm to ghostty-web. Test your addons, since full compatibility is a stated aim.

How does libghostty compare to libvterm and VTE?

All three keep terminal state, for different jobs. libvterm is a small MIT-licensed C99 library by Paul Evans that Neovim embeds today and Qt Creator ships at version 0.3.3. VTE is GNOME's GTK terminal library, licensed LGPL-3.0-or-later, which gives you a finished widget and ties you to GTK. libghostty-vt is MIT licensed, runs from Windows to WebAssembly and bare metal, and Neovim has an approved pull request to adopt it.

How do you embed a terminal emulator in your app with libghostty-vt?

Download and verify the 1.0.0 release tarballs, build them with Zig 0.17, and link the library through pkg-config or CMake. Create a terminal with ghostty_terminal_new, pass every byte from your pty to ghostty_terminal_vt_write, and read the state back with the formatter or the render-state API. Your own code draws the cells, owns the pty and encodes keys with the library's key encoder.

Does libghostty include a renderer or a pty?

No. libghostty-vt only parses input and keeps terminal state. The README of Ghostling, the official demo terminal, lists what consumers build themselves: tabs, multiple windows, splits, session management, configuration and a search UI. JetBrains' October 27, 2026 post describes the same split, with libghostty handling parsing and state while the IDE renders. Hashimoto's 2025 plan adds a GPU rendering library later.

Which products use libghostty in 2026?

Mitchell Hashimoto's November 6, 2026 post names JetBrains IDEs, OrbStack, Vercel's Turborepo, devenv, Antithesis for fuzzing TUI programs, the Emacs package Ghostel, Coder's ghostty-web, KDE's experimental Kwi terminal, and newer terminal tools such as cmux and herdr. Neovim has an approved but unmerged pull request to switch from libvterm, and the awesome-libghostty list tracks well over a hundred projects.

Can I switch the JetBrains terminal back from libghostty?

Yes. JetBrains' October 27, 2026 announcement says the libghostty-based engine is on by default in the reworked terminal from the 2026.3 builds. To return to JediTerm, open Help, Find Action, Registry and turn off terminal.use.ghostty.emulator, then report the problem on issue IJPL-218849. The IntelliJ IDEA 2026.3 documentation adds that SSH sessions still run on the Classic engine.

What do you need to build libghostty-vt from source?

You need Zig. PACKAGING-LIBGHOSTTY.md says libghostty-vt 1.0.0 requires Zig 0.17.x and that Zig 0.16 and 0.18 will not work. Each release ships a signed source tarball and a dependencies tarball in Zig's cache layout, so a --system build needs no internet access. The default build bundles simdutf and Google Highway, and distributions can link system copies with -fsys flags.

The terminal you never chose

Most developers will never pick libghostty. They'll get it inside tools they already use, and since November 6 more of those tools share one MIT-licensed core. If your product has a box that prints process output, one question is worth asking this quarter: are you still maintaining a terminal emulator you never meant to build?