When a DCS sequence has more than MAX_PARAMS parameters, entering
dcs_passthrough would write to params[params_idx] without a bounds
check, causing an out-of-bounds access. Add the same guard that
csi_dispatch already has.
Found by AFL fuzzing, test and fix produced by Codex.
When a DCS sequence has more than MAX_PARAMS parameters, entering
dcs_passthrough would write to params[params_idx] without a bounds
check, causing an out-of-bounds access. Drop the entire DCS hook
when params overflow, consistent with how csi_dispatch handles it.
Found by AFL fuzzing.
We haven't used or run these in forever (literally like 3+ years).
They're just wasting cognitive space and confuse some users as to what
they're for. Remove them.
We haven't used or run these in forever (literally like 3+ years).
They're just wasting cognitive space and confuse some users as to what
they're for. Remove them.
I'd like to contribute a fix for an issue I found regarding how macOS
window restoration works when a window is closed via Cmd+W (leaving the
app active).
Currently, the position cascades down and to the right on every reopen,
and size explicitly resets. Also, explicit `window-position-x/y` configs
get ignored on first launch.
I've diagnosed the issues:
1. In `TerminalWindow.swift`, `setInitialWindowPosition` relies on the
`TerminalController` which isn't present during `awakeFromNib`. I moved
the `screen.origin` calculation directly into the window class to ensure
fixed coordinates are respected immediately.
2. In `TerminalController.swift`, I consolidated the window spawning
cascade logic into a new `applyCascade(to:hasFixedPos:)` helper. It now
only calls `cascadeTopLeft` if `TerminalController.all.count > 1`
(meaning another window is active) and fixed coords aren't set. If it's
the only window, it anchors exactly where `LastWindowPosition` placed
it.
3. In `LastWindowPosition.swift`, I updated the `save` and `restore`
logic to persist the full `window.frame` (origin + size) instead of just
the origin.
*Disclosure: I used Cursor (Tab) to assist in navigating the codebase
and formatting the Swift code, but I fully understand the AppKit
lifecycle changes and edge cases I'm proposing.*
I have the commit locally formatted with `swiftlint` and ready to push!
While it was renamed from `ko_KR.UTF-8.po` to `ko.po` in #10976,
@uhojin, a Korean locale maintainer, [notes] that “ko_KR [*South*
Korean] makes more sense in locale context just to avoid any potential
confusion between 한국어 vs 조선어”.
Despite `ko_KP` (North Korean) not being present in glibc (as of version
2.43), and the ISO639 maintainers [expressing disapproval of `ko_KP`],
it is possible opinions may change in the future, and individual
opinions may be contested—disambiguating doesn't hurt.
Requesting a review from all involved parties; I wish you ***all* opine
before merging**.
[notes]:
https://github.com/ghostty-org/ghostty/pull/10976#discussion_r2861424171
[expressing disapproval of `ko_KP`]:
https://github.com/ghostty-org/ghostty/pull/10976#discussion_r2861359240
While it was renamed from ko_KR.UTF-8.po to ko.po in #10976, @uhojin,
a Korean locale maintainer, notes [1] that “ko_KR [*South* Korean] makes
more sense in locale context just to avoid any potential confusion
between 한국어 vs 조선어”.
Despite ko_KP (North Korean) not being present in glibc (as of version
2.43), and the ISO639 maintainers expressing disapproval of ko_KP [2],
it is possible opinions may change in the future, and individual
opinions may be contested—disambiguating doesn't hurt.
[1]: https://github.com/ghostty-org/ghostty/pull/10976#discussion_r2861424171
[2]: https://github.com/ghostty-org/ghostty/pull/10976#discussion_r2861359240
This fixes two overlapping issues regarding window positioning and Cmd+W window closures on macOS:
1. `window-position-x` and `window-position-y` coordinates were being ignored on initial launch because `TerminalWindow.setInitialWindowPosition` depended on the `TerminalController`, which isn't fully attached during `awakeFromNib`. This logic was moved so explicit coordinates are correctly enforced.
2. When closing a window via Cmd+W (leaving the app active), reopening the window would continuously cascade down and to the right rather than restoring to the previous position. It now checks if there are other windows open before cascading.
3. `LastWindowPosition` was updated to save both the frame origin and size (width/height), ensuring that restoring a closed window correctly mimics native AppKit State Restoration size behaviors while honoring explicit configurations.
That line was intended to guide those who do not normally edit po files
with a plain text editor, but ended up sounding like it states the
obvious (“to do X, do X”) before this change.
“always include a language and a country code” reads as “always include
a language, and also always include a country code”, while the intended
meaning was that it includes both a language *code* and a country code.
Following the discussion at #10852, I believe this is the right default.
I'm willing to continue to revisit this decisions, but Ghostty 1.3 is
around the corner and I don't think such a change like this should be
pushed into it.
This was proposed before but I wanted to wait to iron out any bugs here
and I think we have. Namely we identified one bug where we were
accidentally overriding our _default_ palette which shouldn't happen.
But now that it has sat awhile and we've gathered enough feedback, I'm
willing to commit to it.
In general, we got **very little negative feedback.** The linked
discussion shows very little activity relative to other more
controversial changes we've made. It has basically 1 upvote with around
5 participants whereas our most popular or breaking features/bugs have
had at least dozens if not over a hundred. I think this shows that this
change isn't that disruptive, either because the colors work fine or
because not that many things use the 256-color palette (probably the
latter moreso but a mix for sure). For that reason, I do think
revisiting this at some point is warranted.
I think palette generation is best left as a _theme author_ tool. A
Ghostty color theme could include `palette-generate=true` if it wants to
customize the 256-color palette more easily. Of course, end users can as
well anytime.
Another part of my reasoning is that TUI programs who want this behavior
can already achieve it themselves by mixing dark/light theme detection
via CSI 996
(https://contour-terminal.org/vt-extensions/color-palette-update-notifications/)
with OSC 4/10/11 color query and change sequences, both of which are
decently supported in the terminal ecosystem and fully supported in
Ghostty.
I'm also open to considering some kind of new sequence to make this
easier for TUIs (probably a mode) where they can opt-in to palette
generation plus "harmonius" palettes (see `palette-harmonius`) and
Ghostty does it on demand then. I think that'd solve the legacy vs new
TUI argument where legacy programs can continue to make assumptions
about the palette and new programs can opt-in to a more dynamic palette
without having to do a lot of work themselves.
cc @jake-stewart
Following the discussion at #10852, I believe this is the right default.
I'm willing to continue to revisit this decisions, but Ghostty 1.3 is
around the corner and I don't think such a change like this should be
pushed into it.
I think palette generation is best left as a _theme author_ tool. A
Ghostty color theme could include `palette-generate=true` if it wants
to customize the 256-color palette more easily. Of course, end users can
as well anytime.
Another part of my reasoning is that TUI programs who want this behavior
can already achieve it themselves by mixing dark/light theme detection
via CSI 996 (https://contour-terminal.org/vt-extensions/color-palette-update-notifications/)
with OSC 4/10/11 color query and change sequences, both of which are
decently supported in the terminal ecosystem and fully supported in
Ghostty.
I'm also open to considering some kind of new sequence to make this
easier for TUIs (probably a mode) where they can opt-in to palette
generation plus "harmonius" palettes (see `palette-harmonius`) and
Ghostty does it on demand then. I think that'd solve the legacy vs new
TUI argument where legacy programs can continue to make assumptions
about the palette and new programs can opt-in to a more dynamic palette
without having to do a lot of work themselves.
## Summary
Ports the phantom mouse-motion position-equality check from the GTK
runtime to the embedded runtime (used by macOS).
On macOS, TUI apps like Zellij that frequently update the window title
cause phantom `mouseMoved` events at the same coordinates. These flow
through `embedded.zig` → `Surface.zig` `cursorPosCallback` →
`showMouse()`, which explicitly calls
`NSCursor.setHiddenUntilMouseMoves(false)` and unhides the cursor,
defeating `mouse-hide-while-typing`.
The GTK runtime already filters these in PR #4973 (for #3345):
```zig
const is_cursor_still = @abs(priv.cursor_pos.x - pos.x) < 1 and
@abs(priv.cursor_pos.y - pos.y) < 1;
if (is_cursor_still) return;
```
This PR adds the same check to `embedded.zig`'s `cursorPosCallback`,
using the already-stored `self.cursor_pos` field.
## Test plan
- [x] Enable `mouse-hide-while-typing = true` in Ghostty config
- [ ] Run a TUI app that updates the window title frequently (e.g.
Zellij)
- [ ] Type — cursor should hide and stay hidden despite title updates
- [ ] Move the mouse — cursor should reappear normally
- [ ] Verify no regressions with normal mouse movement,
focus-follows-mouse, or link hovering
Depends on #11030
- Update constraints of `TerminalGlassView`
- Use `TerminalViewContainer.DerivedConfig` to map styling properties
- Add TerminalViewContainerTests
- Instead of using delay, now the view updates are explicitly called by
window controllers
Implements parsing for OSC 3008, which allows terminal emulators to keep
track of the stack of processes that have current control over the tty.
The implementation mirrors existing `semantic_prompt.zig` architecture
and natively maps UAPI definitions to Zig structures with lazy
evaluation for optional metadata.
Fixes#10900
On macOS, TUI apps like Zellij that frequently update the window title
cause phantom mouse-move events to be generated at the same coordinates.
These phantom events reach cursorPosCallback in the core, which calls
showMouse() and explicitly unhides the cursor via
NSCursor.setHiddenUntilMouseMoves(false), defeating the
mouse-hide-while-typing feature.
This ports the same position-equality check already present in the GTK
runtime (added in PR #4973 for issue #3345) to the embedded runtime used
by macOS. If the cursor position hasn't changed by more than 1px, the
event is discarded.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Use `std.meta.stringToEnum` in ContextType and ExitStatus
- Ensure `parseInt` only accepts digits for pids
- Use `@tagName` for string representation in Field
- Rename `fields_raw` to `metadata`
- Rename `readField` to `readOption`
* ensure that `ghostty.h` compiles during basic Zig tests
* ensure that non-exhaustive enums are kept synchronized between
`ghostty.h` and their respective Zig counterpart.
* adjust some enums that varied from established conventions
Implements parsing for OSC 3008, which allows terminal emulators to keep track of the stack of processes that have current control over the tty. The implementation mirrors existing `semantic_prompt.zig` architecture and natively maps UAPI definitions to Zig structures with lazy evaluation for optional metadata.
Fixes#10900
* ensure that `ghostty.h` compiles during basic Zig tests
* ensure that non-exhaustive enums are kept synchronized between
`ghostty.h` and their respective Zig counterpart.
* adjust some enums that varied from established conventions
Optionally see individual commit descriptions.
Re review requests:
- I'm requesting a review from @pluiedev because she wrote the document.
Feel free to ignore or remove your request.
- @jcollie's text about CODEOWNERS from #10976 was rewritten, so I felt
it would be appropriate to ask jcollie to check the new text.
Fixes#11029 (probably)
If you renamed the app bundle, the prior check would infinite loop due
to the combination of two bugs: invalid termination checks and
hardcoding "Ghostty.app"
Fixes#11029 (probably)
If you renamed the app bundle, the prior check would infinite loop due
to the combination of two bugs: invalid termination checks and
hardcoding "Ghostty.app"
trag1c or I point these out manually whenever we see them, but they're
extremely common and probably deserve being explicitly documented.
“Style Guide” was made sentence case because no other title is in title
case.
Before anyone comments: I use “full stop” instead of “period” because
the Unicode Character Database uses “full stop” instead of “period”, and
I avoid “dot” because Unicode has a plethora of dots.
