a5a914c2b8
Chugging along towards #189 This adds significantly more internal work for searching. A long time ago, I added #2885 which had a hint of what I was thinking of. This simultaneously builds on this and changes direction. The change of direction is that instead of making PageList fully concurrency safe and having a search thread access it concurrently, I'm now making an architectural shift where our search thread will grab the big lock (blocking all IO/rendering), but with the bet that we can make our critical areas small enough and time them well enough that the performance hit while actively searching will be minimal. **Results yet to be seen, but the path to implement this is much, much simpler.** ## Rearchitecting Search To that end, this PR builds on #2885 by making `src/terminal/search` and entire package (rather than a single file). ```mermaid graph TB subgraph Layer5 ["<b>Layer 5: Thread Orchestration</b>"] Thread["<b>Thread</b><br/>━━━━━━━━━━━━━━━━━━━━━<br/>• MPSC queue management<br/>• libxev event loop<br/>• Message handling<br/>• Surface mailbox communication<br/>• Forward progress coordination"] end subgraph Layer4 ["<b>Layer 4: Screen Coordination</b>"] ScreenSearch["<b>ScreenSearch</b><br/>━━━━━━━━━━━━━━━━━━━━━<br/>• State machine (tick + feed)<br/>• Result caching<br/>• Per-screen (alt/primary)<br/>• Composes Active + History search<br/>• Interrupt handling"] end subgraph Layer3 ["<b>Layer 3: Domain-Specific Search</b>"] ActiveSearch["<b>ActiveSearch</b><br/>━━━━━━━━━━━━━━━━━━━━━<br/>• Active area only<br/>• Invalidate & re-search<br/>• Small, volatile data"] PageListSearch["<b>PageListSearch</b><br/>━━━━━━━━━━━━━━━━━━━━━<br/>• History search (reverse order)<br/>• Separated tick/feed ops<br/>• Immutable PageList assumption<br/>• Garbage pin detection"] end subgraph Layer2 ["<b>Layer 1: Primitive Operations</b>"] SlidingWindow["<b>SlidingWindow</b><br/>━━━━━━━━━━━━━━━━━━━━━<br/>• Manual linked list node management<br/>• Circular buffer maintenance<br/>• Zero-allocation search<br/>• Match yielding<br/>• Page boundary handling"] end Thread --> ScreenSearch ScreenSearch --> ActiveSearch ScreenSearch --> PageListSearch ActiveSearch --> SlidingWindow PageListSearch --> SlidingWindow classDef layer5 fill:#0a0a0a,stroke:#ff0066,stroke-width:3px,color:#ffffff classDef layer4 fill:#0f0f0f,stroke:#ff6600,stroke-width:3px,color:#ffffff classDef layer3 fill:#141414,stroke:#ffaa00,stroke-width:3px,color:#ffffff classDef layer2 fill:#1a1a1a,stroke:#00ff00,stroke-width:3px,color:#ffffff class Thread layer5 class ScreenSearch layer4 class ActiveSearch,PageListSearch layer3 class SlidingWindow layer2 style Layer5 fill:#050505,stroke:#ff0066,stroke-width:2px,color:#ffffff style Layer4 fill:#080808,stroke:#ff6600,stroke-width:2px,color:#ffffff style Layer3 fill:#0c0c0c,stroke:#ffaa00,stroke-width:2px,color:#ffffff style Layer2 fill:#101010,stroke:#00ff00,stroke-width:2px,color:#ffffff ``` Within the package, we have composable layers that let us test each point: - `SlidingWindow`: The lowest layer, the caller manually adds linked list page nodes and it maintains a sliding window we search over, yielding results without allocation (besides the circular buffers to maintain the sliding window). - `PageListSearch`: Searches a PageList structure in reverse order (assumption: more recent matches are more valuable than older), but separates out the `tick` (search, but no PageList access) and `feed` (PageList access, prep data for search but don't search) operations. This lets us `feed` in a critical area and `tick` outside. **This assumes an immutable PageList, so this is for history.** - `ActiveSearch`: Searches only the active area of a PageList. The expectation is that the active area changes much more regularly, but it is also very small (relative to scrollback). Throws away and re-searches the active area as necessary. - `ScreenSearch`: Composes the previous three components to coordinate searching an active terminal screen. You'd have one of these per screen (alt vs primary). This also caches results unlike the other components, with the expectation that the caller will revisit the results as screens change (so if you switch from neovim back to your shell and vice versa with a search active, it won't start over). - `Thread`: A dedicated search thread that will receive messages via MPSC queues while managing the forward progress of a `ScreenSearch` and sending matches back to the surface mailbox for apprt rendering. **The thread component is not functional, just boilerplate, in this PR.** ScreenSearch is a state machine that moves in an iterative `tick` + `feed` fashion. This will let us "interrupt" the search with updates on the search thread (read our mailbox via libxev loops for example) and will let us minimize critical areas with locks (only `feed`). Each component is significantly unit tested, especially around page boundary cases. Given the complexity, there is no way this is perfect, but the architecture is such that we can easily add regression tests as we find issues. ## Other Changes, Notes The only change to actually used code is that tracked pins in a `PageList` can now be flagged as "garbage." A garbage tracked pin is one that had to be moved in a non-sensical way because the previous location it tracked has been deleted. This is used by the searcher to detect that our history was pruned. **If my assumption about the big lock is wrong** and this ends up being godawful for performance, then it should still be okay because more granular locking and reference counting such as that down by @dave-fl in #8850 can be pushed into these components and reused. So this work is still valuable on its own. ## Future This PR is still just a bunch of internals, split out into its own PR so I don't make one huge 10K diff PR. There are a number of future tasks: - Flesh out `ScreenSearch` and hook it up to `Thread` - Pull search thread management into `Surface` (or possibly the render thread or shared render state since active area changes can be synchronized with renderer frame rebuilds. Not sure yet.) - Send updates back to the surface thread so that apprts can update UI. - Apprt actions, input bindings, etc. to hook this all up (the easy part, really). The next step is to continue to flesh out the `ScreenSearch` as required and hook it up to `Thread`. **AI disclosure:** AI reviewed the code and assisted with some tests, but didn't write any of the logic or design. This is beyond its ability (or my ability to spec it out clearly enough for AI to succeed). |
||
|---|---|---|
| .agents/commands | ||
| .github | ||
| dist | ||
| example | ||
| flatpak | ||
| images | ||
| include | ||
| macos | ||
| nix | ||
| pkg | ||
| po | ||
| snap | ||
| src | ||
| test | ||
| vendor | ||
| .clang-format | ||
| .editorconfig | ||
| .envrc | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| .prettierignore | ||
| AGENTS.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| Doxyfile | ||
| DoxygenLayout.xml | ||
| HACKING.md | ||
| LICENSE | ||
| Makefile | ||
| PACKAGING.md | ||
| README.md | ||
| build.zig | ||
| build.zig.zon | ||
| build.zig.zon.json | ||
| build.zig.zon.nix | ||
| build.zig.zon.txt | ||
| default.nix | ||
| flake.lock | ||
| flake.nix | ||
| shell.nix | ||
| typos.toml | ||
| valgrind.supp | ||
README.md
Ghostty
Fast, native, feature-rich terminal emulator pushing modern features.
About
·
Download
·
Documentation
·
Contributing
·
Developing
About
Ghostty is a terminal emulator that differentiates itself by being fast, feature-rich, and native. While there are many excellent terminal emulators available, they all force you to choose between speed, features, or native UIs. Ghostty provides all three.
In all categories, I am not trying to claim that Ghostty is the best (i.e. the fastest, most feature-rich, or most native). But Ghostty is competitive in all three categories and Ghostty doesn't make you choose between them.
Ghostty also intends to push the boundaries of what is possible with a terminal emulator by exposing modern, opt-in features that enable CLI tool developers to build more feature rich, interactive applications.
While aiming for this ambitious goal, our first step is to make Ghostty one of the best fully standards compliant terminal emulator, remaining compatible with all existing shells and software while supporting all of the latest terminal innovations in the ecosystem. You can use Ghostty as a drop-in replacement for your existing terminal emulator.
For more details, see About Ghostty.
Download
See the download page on the Ghostty website.
Documentation
See the documentation on the Ghostty website.
Contributing and Developing
If you have any ideas, issues, etc. regarding Ghostty, or would like to contribute to Ghostty through pull requests, please check out our "Contributing to Ghostty" document. Those who would like to get involved with Ghostty's development as well should also read the "Developing Ghostty" document for more technical details.
Roadmap and Status
The high-level ambitious plan for the project, in order:
| # | Step | Status |
|---|---|---|
| 1 | Standards-compliant terminal emulation | ✅ |
| 2 | Competitive performance | ✅ |
| 3 | Basic customizability -- fonts, bg colors, etc. | ✅ |
| 4 | Richer windowing features -- multi-window, tabbing, panes | ✅ |
| 5 | Native Platform Experiences (i.e. Mac Preference Panel) | ⚠️ |
| 6 | Cross-platform libghostty for Embeddable Terminals |
⚠️ |
| 7 | Windows Terminals (including PowerShell, Cmd, WSL) | ❌ |
| N | Fancy features (to be expanded upon later) | ❌ |
Additional details for each step in the big roadmap below:
Standards-Compliant Terminal Emulation
Ghostty implements enough control sequences to be used by hundreds of testers daily for over the past year. Further, we've done a comprehensive xterm audit comparing Ghostty's behavior to xterm and building a set of conformance test cases.
We believe Ghostty is one of the most compliant terminal emulators available.
Terminal behavior is partially a de jure standard (i.e. ECMA-48) but mostly a de facto standard as defined by popular terminal emulators worldwide. Ghostty takes the approach that our behavior is defined by (1) standards, if available, (2) xterm, if the feature exists, (3) other popular terminals, in that order. This defines what the Ghostty project views as a "standard."
Competitive Performance
We need better benchmarks to continuously verify this, but Ghostty is generally in the same performance category as the other highest performing terminal emulators.
For rendering, we have a multi-renderer architecture that uses OpenGL on Linux and Metal on macOS. As far as I'm aware, we're the only terminal emulator other than iTerm that uses Metal directly. And we're the only terminal emulator that has a Metal renderer that supports ligatures (iTerm uses a CPU renderer if ligatures are enabled). We can maintain around 60fps under heavy load and much more generally -- though the terminal is usually rendering much lower due to little screen changes.
For IO, we have a dedicated IO thread that maintains very little jitter
under heavy IO load (i.e. cat <big file>.txt). On benchmarks for IO,
we're usually within a small margin of other fast terminal emulators.
For example, reading a dump of plain text is 4x faster compared to iTerm and
Kitty, and 2x faster than Terminal.app. Alacritty is very fast but we're still
around the same speed (give or take) and our app experience is much more
feature rich.
[!NOTE] Despite being very fast, there is a lot of room for improvement here.
Richer Windowing Features
The Mac and Linux (build with GTK) apps support multi-window, tabbing, and splits.
Native Platform Experiences
Ghostty is a cross-platform terminal emulator but we don't aim for a least-common-denominator experience. There is a large, shared core written in Zig but we do a lot of platform-native things:
- The macOS app is a true SwiftUI-based application with all the things you would expect such as real windowing, menu bars, a settings GUI, etc.
- macOS uses a true Metal renderer with CoreText for font discovery.
- The Linux app is built with GTK.
There are more improvements to be made. The macOS settings window is still a work-in-progress. Similar improvements will follow with Linux.
Cross-platform libghostty for Embeddable Terminals
In addition to being a standalone terminal emulator, Ghostty is a
C-compatible library for embedding a fast, feature-rich terminal emulator
in any 3rd party project. This library is called libghostty.
Due to the scope of this project, we're breaking libghostty down into
separate actually libraries, starting with libghostty-vt. The goal of
this project is to focus on parsing terminal sequences and maintaining
terminal state. This is covered in more detail in this
blog post.
libghostty-vt is already available and usable today for Zig and C and
is compatible for macOS, Linux, Windows, and WebAssembly. At the time of
writing this, the API isn't stable yet and we haven't tagged an official
release, but the core logic is well proven (since Ghostty uses it) and
we're working hard on it now.
The ultimate goal is not hypothetical! The macOS app is a libghostty consumer.
The macOS app is a native Swift app developed in Xcode and main() is
within Swift. The Swift app links to libghostty and uses the C API to
render terminals.
Crash Reports
Ghostty has a built-in crash reporter that will generate and save crash
reports to disk. The crash reports are saved to the $XDG_STATE_HOME/ghostty/crash
directory. If $XDG_STATE_HOME is not set, the default is ~/.local/state.
Crash reports are not automatically sent anywhere off your machine.
Crash reports are only generated the next time Ghostty is started after a crash. If Ghostty crashes and you want to generate a crash report, you must restart Ghostty at least once. You should see a message in the log that a crash report was generated.
[!NOTE]
Use the
ghostty +crash-reportCLI command to get a list of available crash reports. A future version of Ghostty will make the contents of the crash reports more easily viewable through the CLI and GUI.
Crash reports end in the .ghosttycrash extension. The crash reports are in
Sentry envelope format. You can
upload these to your own Sentry account to view their contents, but the format
is also publicly documented so any other available tools can also be used.
The ghostty +crash-report CLI command can be used to list any crash reports.
A future version of Ghostty will show you the contents of the crash report
directly in the terminal.
To send the crash report to the Ghostty project, you can use the following CLI command using the Sentry CLI:
SENTRY_DSN=https://e914ee84fd895c4fe324afa3e53dac76@o4507352570920960.ingest.us.sentry.io/4507850923638784 sentry-cli send-envelope --raw <path to ghostty crash>
[!WARNING]
The crash report can contain sensitive information. The report doesn't purposely contain sensitive information, but it does contain the full stack memory of each thread at the time of the crash. This information is used to rebuild the stack trace but can also contain sensitive data depending on when the crash occurred.