Fixes#9957
Our `Page.getRowAndCell` uses a _page-relative_ x/y coordinate system
and we were passing in viewport x/y. This has the possibility to leading
to all sorts of bugs, including the crash found in #9957 but also simply
reading the wrong cell even in single-page scenarios.
Fixes#9957
Our `Page.getRowAndCell` uses a _page-relative_ x/y coordinate system
and we were passing in viewport x/y. This has the possibility to leading
to all sorts of bugs, including the crash found in #9957 but also simply
reading the wrong cell even in single-page scenarios.
## macOS: Re-apply custom icon after app build changes
### Summary
Fixes the regression where custom icons are not re-applied after app
updates, particularly affecting users on the tip channel.
### Problem
PR #9670 introduced caching to avoid redundantly setting the app icon on
every launch. However when Ghostty updates, the app bundle is replaced
and the custom icon is reset by macOS. Since `UserDefaults` persists
across updates, the cached icon name still matches the desired icon
name, causing the icon update to be incorrectly skipped.
This was reported by users in #9670 comments as well, that after
updating Ghostty the custom icon would disappear and require manual
re-application.
### Solution
- Track the app build number (`CFBundleVersion`) alongside the icon name
in `UserDefaults`
- Re-apply the icon if either the icon config has changed OR the build
number has changed
- Only update `UserDefaults` if `NSWorkspace.setIcon()` succeeds,
preventing false-positive caching on failure
I used `CFBundleVersion` (build number, e.g. `13509`) rather than
`CFBundleShortVersionString` (e.g. `1.2.3`) because tip builds increment
the build number with each release while the short version string
remains constant. I considered combining both but this seemed redundant.
### Related
- Fixes regression mentioned in comments on #9670
- Original issue: #9666
- Original discussion: #9665
Replaces #9785
This adds session search to the command palette on macOS. Session search
lets you jump to any running terminal based on title or working
directory. The command palette shows you the title, working directory,
and tab color (if any) to help you identify the terminal you care about.
This also enhances our command palette in general to support better
sorting, more stable sorts when keys are identical, etc.
## Demo
https://github.com/user-attachments/assets/602a9424-e182-4651-bf08-378e9c5e1616
## Future
Since this inherits the command palette infrastructure, we don't have
fuzzy search capabilities yet, but I still think this is useful already.
We should add fuzzy searching in the future.
Thanks @phaistonian for the inspiration here but I did do a full
rewrite.
**AI disclosure:** I used AI to assist with this in places, but I
understand everything and touched up almost everything manually.
This PR fixes an issue in the change I merged yesterday (#9921), which
was reported by @quonb. Apology
I verified the fix by testing a wide range of URL schemes:
```
echo "https://example.com"
echo "http://example.com"
echo "mailto:test@example.com"
echo "ftp://example.com/file.txt"
echo "file:/Users/you/file.txt"
echo "ssh:user@example.com"
echo "git://github.com/user/repo.git"
echo "ssh://example.com/path"
echo "tel:+12123456789"
echo "ipns://example.com/path"
echo "gemini://example.com/"
echo "gopher://example.com/1menu"
echo "news:comp.lang.zig"
```
#1123 added a warning when the OpenGL version is too old, but it is
never used because GTK enforces the version set with
gl_area.setRequiredVersion() before prepareContext() is called: we end
up with a generic "failed to make GL context" error:
```
warning(gtk_ghostty_surface): failed to make GL context current: Unable to create a GL context warning(gtk_ghostty_surface): this error is almost always due to a library, driver, or GTK issue warning(gtk_ghostty_surface): this is a common cause of this issue: https://ghostty.org/docs/help/gtk-opengl-context
```
This patch removes the requirement at the GTK level and lets the ghostty
renderer check, now failing as follow:
```
info(opengl): loaded OpenGL 4.2
error(opengl): OpenGL version is too old. Ghostty requires OpenGL 4.3 warning(gtk_ghostty_surface): failed to initialize surface err=error.OpenGLOutdated warning(gtk_ghostty_surface): surface failed to initialize err=error.SurfaceError
```
(Note that this does not render a ghostty window, unlike the previous
error which rendered the "Unable to acquire an OpenGL context for
rendering." view, so while the error itself is easier to understand it
might be harder to view)
-----------------------
I looked for why I couldn't get a context at all mostly to see what
OpenGL 4.3 functions were required to see if there'd be easy fallbacks,
but it also took me a good 15 minutes this morning to understand that
there was nothing wrong with my gtk/mesa versions and it's just my
hardware being old, so I think it'd good to take in itself even if the
displaying itself is a bit meh.
Happy to try to display it in the error page if you think it's important
and I can figure out how (haven't looked much yet)
#1123 added a warning when the OpenGL version is too old, but
it is never used because GTK enforces the version set with
gl_area.setRequiredVersion() before prepareContext() is called:
we end up with a generic "failed to make GL context" error:
warning(gtk_ghostty_surface): failed to make GL context current: Unable to create a GL context
warning(gtk_ghostty_surface): this error is almost always due to a library, driver, or GTK issue
warning(gtk_ghostty_surface): this is a common cause of this issue: https://ghostty.org/docs/help/gtk-opengl-context
This patch removes the requirement at the GTK level and lets the ghostty
renderer check, now failing as follow:
info(opengl): loaded OpenGL 4.2
error(opengl): OpenGL version is too old. Ghostty requires OpenGL 4.3
warning(gtk_ghostty_surface): failed to initialize surface err=error.OpenGLOutdated
warning(gtk_ghostty_surface): surface failed to initialize err=error.SurfaceError
(Note that this does not render a ghostty window, unlike the previous
error which rendered the "Unable to acquire an OpenGL context for
rendering." view, so while the error itself is easier to understand it
might be harder to view)
This is a subcommand I've been using for some time. It takes an optional
issue/PR number as context and produces a prompt to review a branch for
how well it addresses the issue along with any isolated issues it spots.
Example:
https://ampcode.com/threads/T-019b2877-475f-758d-ae88-93c722561576
This is a subcommand I've been using for some time. It takes an optional
issue/PR number as context and produces a prompt to review a branch for
how well it addresses the issue along with any isolated issues it spots.
Example: https://ampcode.com/threads/T-019b2877-475f-758d-ae88-93c722561576
Related Issue: #5047
Discussion: #4664
### Investigation
The behavior of iTerm mentioned on the Discussion thread was as follows:
- `cmd + u` can be used to toggle "Use Transparency"
- The "Use Transparency" toggle operates on a per-surface basis
- The "Use Transparency" state persists even after reloading the config
### Summary
Based on the investigation and discussions in the preceding pull
requests, this implements the `toggle_background_opacity` keybind action
for macOS with the following specifications:
- Switches background opacity on a per-surface basis
- The background opacity state persists even after reloading the config
- Background opacity switching functionality is also available in Quick
Terminal
- Does nothing if `background-opacity` is set to 1 or higher
- Does nothing if in fullscreen mode
### Verification
This functionality has been tested across following scenarios,
confirming correct action behavior for:
- Split Window
- Each split window maintains synchronized background opacity states
- Tab Group
- Background opacity states do not synchronize between tabs
- Quick Terminal
- Background opacity states remain synchronized even when windows are
closed
- Command Palette
### AI Disclosure
This pull request was made with assistance from Claude Code.
I reviewed all AI-generated code and wrote the final output manually.
https://github.com/user-attachments/assets/e46ff8f0-42f2-442f-97dd-d5f5c33b10f1
This PR fixes an issue #9563 where relative file paths were not being
resolved against the terminal’s current working directory before
opening.
#### Verification
Tested with directories containing:
```
/tmp/test/test
❯ du -h .
0B ./spaces-end
0B ./with dot.
0B ./space middle
8.0K .
```
Parent directory resolution also works as expected:
```
/tmp/test/test
❯ du -h ..
0B ../test/spaces-end
0B ../test/with dot.
0B ../test/space middle
8.0K ../test
16K ..
```
@mitchellh
In your original description you mentioned that “Links should work for all situations as they do in iTerm2.”
I noticed that, for example, when running `ls`, the paths are not clickable, while they are clickable in iTerm2.
If you think this case should also be handled, I can open a separate PR for it once this one is accepted.
Implements #8399.
I didn't save `position` in this pr, since I don't see its necessity.
Changing `quick-terminal-position` requires a relaunch; saving and
restoring this would have to deal with conflicts. I also don't see why a
user would change this frequently.
> [!NOTE]
> Used GPT to proofread my comments
This adds a couple optimizations to our CI:
1. macOS matrix gone, only test that freetype builds in addition to
Coretext.
2. Move Flatpak out to a triggered build on main similar to snaps. This
was our longest build and avoiding it in PRs is a win since it rarely
fails.
Mitchell Hashimoto