mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-09-22 08:02:24 +00:00
l0ng-ai
83676d2e01
gpui derives `key_char` by running the event's virtual keycode back through the current layout; it never reads the event's Unicode payload. That is fine for a physical keyboard, but remote-control apps synthesize keystrokes as `CGEventCreateKeyboardEvent(src, 0, ...)` + `CGEventKeyboardSetUnicodeString()`, putting the real text only in the payload. Keycode 0 is `a`, so every character typed from a phone arrived in the terminal as `a`. gpui does divert printable keys to the input context, but only while a composing input source is active (`is_ime_input_source_active`), so the bug appeared and vanished depending on the selected input method — and the plain ABC layout, the macOS default, always lost the text. Make the IME the single delivery path for text on macOS: `on_key_down` declines plain printable keys without consuming them, so gpui falls through to `handleEvent:` and the Unicode payload survives into `commit_text`. Chords are excluded — Ctrl/Cmd/Fn belong to the encoders, Option to the Meta policy — and a pending multi-key chord still wins, matching `prefers_ime_for_printable_keys`. Answer `apple_press_and_hold_enabled()` with false as well. `on_key_down` used to consume printable keys before gpui consulted it; now that gpui reaches its held-key branch, false is what keeps auto-repeat instead of handing the key to the accent palette — a terminal wants `jjj`, not `ĵ`. Tests that assert on text input now go through a `type_char` helper that follows the platform: `commit_text` on macOS, `on_key_down` elsewhere. Building a `KeyDownEvent` by hand exercised a path macOS no longer takes. Production semantics are unchanged: `input_active()` is already false at a shell vi-mode prompt and `write_gap_text` has its own `shell_vi_prompt()` branch. Linux is unaffected and still uses the `key_char` path, since gpui's IBus integration does not commit plain ASCII back through `replace_text_in_range`.
tty7
A terminal workbench: shells, sessions, SSH, coding agents.
Pure Rust · GPU rendering on Zed's gpui · VT core from Alacritty
English · 简体中文
Why
- Fast — ~2× the throughput of Alacritty, Ghostty, or Kitty (benchmarks)
- Sessions persist — quit or reboot; your shells keep running, no tmux
- Editor-grade input — completion, syntax highlighting, history search built in; zero config for zsh, bash, fish, PowerShell
- Agent-aware — recognizes Claude Code & co. in a pane: status, notifications, session resume
Install
Native builds for each platform on Releases:
| macOS | …-macos-arm64.dmg · …-x86_64.dmg |
drag into Applications |
| Windows | …-setup.exe · portable ….zip |
|
| Linux | …-x86_64.AppImage |
chmod +x and run — x11/wayland libs bundled |
What's inside
| Input | ghost suggestions from history · explained tab completion · syntax highlighting · multi-line editing · click places the caret · ⌃ R fuzzy history |
| Window | tabs & splits · ⌘ P palette · ⌘ F scrollback search · eight themes · IME |
| Coding agents | per-pane agent detection (~17 CLIs): status dot, notifications, branch + diff, resume after reboot, tray icon that signals "needs your input" |
| SSH | native russh stack: profiles with keychain secrets, SFTP panel, port forwarding, jump hosts |
Details for every row: docs/features.md. Keybindings: ⌘ , opens Settings — browse and remap everything, tmux preset included (full list).
Benchmarks
Same machine, same day, same 155×40 grid — Apple M1 Pro, macOS 26.3.1, five-run averages (2026-07-04):
| tty7 | Alacritty | Ghostty | Kitty | |
|---|---|---|---|---|
Plaintext IO — 11 MB cat (lower = better) |
95 ms | 239 ms | 179 ms | 185 ms |
| DOOM-fire frame rate (higher = better) | 888 fps | 485 fps | 552 fps | 617 fps |
| Cold-launch memory | 116 MB¹ | 105 MB | 128 MB | 130 MB |
¹ GUI 105 MB + the persistent daemon 11 MB.
Methodology and one-command reproduction: scripts/bench/.
Built on gpui and alacritty_terminal · Apache-2.0 · Discord · Changelog