Fixes https://github.com/ghostty-org/ghostty/discussions/11203
The `suppressNextLeftMouseUp` flag from #11167 wasn't being reset on
focus loss, causing stale state that led to phantom drags/selections and
scrolls if you're lucky enough.
I've followed the #11167 's path and made it reset on focus loss.
As I stated in the [vouch
request](https://github.com/ghostty-org/ghostty/discussions/11274); I'm
not experienced in Swift, just following the prior PR's steps to reset
the state. I've been using this patch for couple days and the change
looks trivial to me tho not 100% sure if I'm missing anything.
> [!NOTE]
> Used Claude Code -Opus 4.6- for navigating the codebase and reviewing
the change.
Fixes phantom mouse drag/selection when switching splits or apps.
The suppressNextLeftMouseUp flag and core mouse click_state were not
being reset on focus transitions, causing stale state that led to
unexpected drag behavior.
- Reset suppressNextLeftMouseUp in focusDidChange when losing focus
- Defensively reset the flag when processing normal clicks
- Reset core mouse.click_state and left_click_count on focus loss
## Summary
- After finishing an inline tab title edit (via keybind or
double-click), all keyboard input is lost because
`TabTitleEditor.finishEditing()` sets `makeFirstResponder(nil)`, leaving
the window itself as first responder with no path back to the terminal
surface.
- Adds a `tabTitleEditorDidFinishEditing` delegate callback to
`TabTitleEditorDelegate` that fires after every edit (commit or cancel).
- `TerminalWindow` implements it by calling
`makeFirstResponder(focusedSurface)` to restore keyboard focus to the
terminal.
Fixes https://github.com/ghostty-org/ghostty/discussions/11315
## Testing
- [x] Bind `prompt_tab_title` to a keybind (e.g. `keybind =
cmd+shift+i=prompt_tab_title`)
- [x] Trigger inline tab title edit via keybind, press Enter — verify
keyboard input works immediately
- [x] Trigger inline tab title edit via keybind, press Escape — verify
keyboard input works immediately
- [x] Double-click a tab title, press Enter — verify keyboard input
works immediately
- [x] Double-click a tab title, press Escape — verify keyboard input
works immediately
- [x] Verify Cmd+number tab switching works after all of the above
- [x] Verify split pane focus is correct after editing tab title with
splits open
AI disclosure: Codebase exploration and review via [Claude
Code](https://claude.com/claude-code)
After finishing an inline tab title edit (via keybind or double-click),
`TabTitleEditor.finishEditing()` calls `makeFirstResponder(nil)` to
clear focus from the text field, leaving the window itself as first
responder. No code path restores focus to the terminal surface, so all
keyboard input is lost until the user clicks into a pane.
Add a `tabTitleEditorDidFinishEditing` delegate callback that fires
after every edit (commit or cancel). TerminalWindow implements it by
calling `makeFirstResponder(focusedSurface)` to hand focus back to the
terminal.
Fixes https://github.com/ghostty-org/ghostty/discussions/11315
Co-Authored-By: Claude <noreply@anthropic.com>
Add initialContentSize fallback on TerminalViewContainer so
intrinsicContentSize returns the correct value immediately,
without waiting for @FocusedValue to propagate. This removes
the need for the DispatchQueue.main.asyncAfter 40ms delay.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Tests that validate intrinsicContentSize returns a correct value when
TerminalController.windowDidLoad() reads it. Currently fail, proving
the race condition where @FocusedValue hasn't propagated
lastFocusedSurface before the 40ms timer fires.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fixes#11256, which is rather hard to reproduce on macOS 26, but after
adding breaking points on size update, we can see that it happens when
the `intrinsicContentSize` is not properly updated.
<img width="998" height="556" alt="Xnip2026-03-09_11-38-40"
src="https://github.com/user-attachments/assets/8ac1de91-5895-45fc-a443-002eb016a1ce"
/>
When a grapheme expands to width 2 at the screen edge, this path can
write spacer_head before printWrap() sets row.wrap. With an active
hyperlink, printCell triggers hyperlink bookkeeping and page integrity
checks in that intermediate state, causing UnwrappedSpacerHead.
Mark row.wrap before writing spacer_head in this grapheme-wrap path to
keep the intermediate state valid.
When a grapheme expands to width 2 at the screen edge, this path can write
spacer_head before printWrap() sets row.wrap. With an active hyperlink,
printCell triggers hyperlink bookkeeping and page integrity checks in that
intermediate state, causing UnwrappedSpacerHead.
Mark row.wrap before writing spacer_head in this grapheme-wrap path to keep
the intermediate state valid.
This fixes an error if the script was sourced a second time:
bash: __ghostty_ps0: readonly variable
Because this is a non-exported variable, this would only happen if the
script was sourced multiple times in the same bash session.
If an existing PROMPT_COMMAND was a string ending in ; (and maybe some
spaces), we'd add a redundant ;, resulting in a syntax error. Now we
strip any trailing `;[[:space:]]*` characters from the original string
before add ours.
Fixes#11259
If an existing PROMPT_COMMAND was a string ending in ; (and maybe some
spaces), we'd add a redundant ;, resulting in a syntax error. Now we
strip any trailing `;[[:space:]]*` characters from the original string
before add ours.
This fixes an error if the script was sourced a second time:
bash: __ghostty_ps0: readonly variable
Because this is a non-exported variable, this would only happen if the
script was sourced multiple times in the same bash session.
- "Unable to acquire an OpenGL context for rendering."
This could be translated to "No se puede" or "No se pudo", depends on
the context of the message.
If the message is showing a current intent the translation should be "No
se puede", if the message is communicating that Ghostty failed to
acquire the OpenGL then the translation should be "No se pudo", here I
need more context.
Either case the wording "No se puedo" is incorrect.
This adds two new propeties to make it easy to get the frontmost (main)
window and the focused terminal within a tab. We already had a property
to get the selected tab of a tab group.
## Examples
### Send Input to Focused Terminal
```AppleScript
tell application "Ghostty"
set term to focused terminal of selected tab of front window
input text "pwd\n" to term
end tell
```
### Split the Focused Terminal
```applescript
tell application "Ghostty"
set currentTerm to focused terminal of selected tab of front window
set newTerm to split currentTerm direction right
input text "echo split-ready\n" to newTerm
end tell
```
This adds two new propeties to make it easy to get the frontmost (main)
window and the focused terminal within a tab. We already had a property
to get the selected tab of a tab group.
If you have multiple splits and start searching naturally the focus
transfers over to the search widget which would apply the unfocused
options. This could make it difficult to view your matches from
searching without re-focusing the surface.
This was discovered when I tested
https://github.com/ghostty-org/ghostty/discussions/11218 (which is a
different issue)
Remove the stale GHOSTTY_SGR_ATTR_RESET_UNDERLINE entry from the C
header and renumber subsequent GhosttySgrAttributeTag values to match
src/terminal/sgr.zig Attribute.Tag ordering.
This fixes misclassified attributes from ghostty_sgr_next for C
consumers that switch on the enum tags from include/ghostty/vt/sgr.h.
Remove the stale GHOSTTY_SGR_ATTR_RESET_UNDERLINE entry from the C header
and renumber subsequent GhosttySgrAttributeTag values to match
src/terminal/sgr.zig Attribute.Tag ordering.
This fixes misclassified attributes from ghostty_sgr_next for C consumers
that switch on the enum tags from include/ghostty/vt/sgr.h.
Add `aid=$pid` to 133;A and 133;D for nested shell tracking, and fix the
state comparison which was incorrectly using `constantly` (comparing a
string to a function, which always evaluated to true).
OSC 133;B (input start) and 133;P;k=r (right prompt) cannot be reliably
implemented at the script level because Elvish escapes control
characters in prompt function output, and writing directly to /dev/tty
has timing issues because Elvish renders its prompts on a background
thread. Full semantic prompt support requires a native implementation:
https://github.com/elves/elvish/pull/1917
See: #10523
