Discussed in https://github.com/ghostty-org/ghostty/discussions/10739
## Summary
Remove the hardcoded opaque background (alpha=255) from IME preedit
cells so they respect `background-opacity` like all other cells.
When `background-opacity` is less than 1, preedit (composition) text was
rendered with a fully opaque background, causing the text to appear
highlighted and hard to read. This change removes the explicit per-cell
background from `addPreeditCell`, letting preedit cells fall through to
the global background. The underline indicator is preserved to mark the
preedit region.
---
`background-opacity` が 1
未満のとき、IME入力中（preedit）のセルが完全不透明な背景で描画され、ハイライトされたように見えて読みづらくなる問題を修正しました。
`addPreeditCell` のセル背景描画を削除し、グローバル背景に委ねることで通常セルと同じ透過表示になります。
preedit領域のアンダーラインは維持されます。
## Test plan
- Set `background-opacity` to a value less than 1 (e.g. 0.5)
- Type Japanese (or other IME input) to trigger preedit
- Verify preedit text no longer appears highlighted
- Verify the underline indicator is still drawn under preedit text
AI disclosure: I used Claude Code to investigate the source code and
generate code changes in this PR.
Fixes#10424
Replaces #10431
The issue is that when the row where preedit was wasn't dirty, we were
layering more preedit cells (identical ones) on top, so it'd appear to
get "thicker".
Closes#9880.
https://github.com/user-attachments/assets/7110fae1-a7ca-42b6-8956-833b8bdd5d98
> [!NOTE]
>
> Used AI to get to explain to me some of the APIs and functionality
between `windows` and `tabs` and their connections. But the code itself,
I implemented everything, just used it for help with explaining some
things
## If you feel like reading more:
- I feel there is a lot of duplication now with the `prompt surface
title` functionality. For the dialog creation, i basically copied-pasted
the `surface_title_dialog`, and some of the `titleOverride` and the
`TabDialogSet` functionality is identical to that of the
`prompt_surface_title`
- I would think about abstracting it out, but first I think Id be nice
to think what the maintainers think about this approach before doing
anything else.
Fixes#10424
Replaces #10431
The issue is that when the row where preedit was wasn't dirty, we were
layering more preedit cells (identical ones) on top, so it'd appear to
get "thicker".
The `cursor` shell feature always used a blinking bar (beam), often to
the surprise of users who set `cursor-style-blink = false`.
This change extends our GHOSTTY_SHELL_FEATURES format to include either
`cursor:blink` (default) or `cursor:steady` based on cursor-style-blink
when the `cursor` feature is enabled, and all shell integrations have
been updated to use that additional information to choose the DECSCUSR
cursor value (5=blinking bar, 6=steady bar).
I also considered passing a DECSCUSR value in GHOSTTY_SHELL_FEATURES
(e.g. `cursor:5`). This mostly worked well, but zsh also needs the blink
state on its own for its block cursor. We also don't support any other
shell feature cursor configurability (e.g. the shape), so this was an
over generalization.
This does change the behavior for users who like the blinking bar in the
shell but have `cursor-blink-style = false` for other reasons. We could
provide additional `cursor` shell feature configurability (e.g.
`cursor:blink` in `shell-integration-features`), but I'll propose that
as its own change.
See: #2812Closes: #8681
---
**AI Disclosure:** I did a lot of rubber ducking with Claude Code while
trying out various ideas. It was particularly useful for this kind of
feature because I could try out one thing and have it evaluate the
impact on all of the shell integration scripts at once.
Our PS1 cleanup code (where we remove any markers we added) was still
looking for the previous 133;A form. Update it to include 'cl=line',
which was added in 8595558.
## Summary
- Fixes#10345 — `copy_title_to_clipboard` now copies the user-set
custom title instead of the raw terminal title
- Adds a new `copy_title` apprt action as [suggested by
@mitchellh](https://github.com/ghostty-org/ghostty/issues/10345#issuecomment-2601002974)
- Each platform (GTK + macOS) resolves the effective title (user
override → terminal title fallback) before copying to clipboard
## Changes
- **`src/apprt/action.zig`** — New `copy_title` void action
- **`include/ghostty.h`** — C ABI enum entry
- **`src/Surface.zig`** — Binding handler now dispatches apprt action
instead of inline logic
- **`src/apprt/gtk/class/surface.zig`** — `getEffectiveTitle()` helper
(returns `title_override orelse title`)
- **`src/apprt/gtk/class/application.zig`** — GTK action handler
- **`macos/.../Ghostty.App.swift`** — macOS handler using
`surfaceView.title` + `NSPasteboard`
*Note*: This PR was *AI* assisted.
The printf was part of the original script (9d6121245), and at the time,
this was the only place we'd emit the 133;A mark.
A PS1-based 133;P;k=i mark was introduced in 2bf1f80f7, and then it
become a full 133;A mark in aa47047a6, making the original printf line
redundant (because bash will also redraw PS1 on SIGWINCH).
The PS1-based 133;A was only missing the aid= option, and with that
added, it handles all of our cases (prompts, initial draw, and resizes).
For a hardcoded set of control characters, replace them with spaces when
encoding pasted text. This is to prevent unsafe control characters from being
pasted which could trick a user into executing commands unexpectedly.
This happens regardless of bracketed paste mode, because certain
characters processed by the kernel pty line discipline can break
bracketed paste (source from zsh:
https://zsh-workers.zsh.narkive.com/Kd3evJ7t/bracketed-paste-mode-in-xterm-and-urxvt).
This behavior is based on xterm's behavior, including the list of
characters. Note that as a comment in the code says, we should be
sourcing some of these from a tcgetattr call instead of hardcoding them,
but this is a good start.
This pull request addresses some of the remaining issues when matching
`~`, `$VAR`, `.directory/`, and embedded commas. It does not address
issues with embedded line breaks.
The PR is split in multiple commits carefully applying a set of changes
to
1. make the big regex more composable / readable
2. update some doc strings
3. add more test cases for the issues mentioned
4. two simple commits, each fixing the issues
Changes:
- **url: refactor regex into documented branches**
Break up the big monolithic URL and path regex into named sub-pattern
constants and compose the final expression from three commented
branches:
- URLs with a scheme
- absolute or dot-relative paths
- bare relative paths
This commit only breaks up the regex. It keeps the existing matching
behavior unchanged.
- **url: update top-level comment**
- **url: carefully extend test cases**
Extend existing test cases with `~`, `$VAR`, and bare .-prefixed paths
and embedded `,` comma handling.
See following issue comments:
-
https://github.com/ghostty-org/ghostty/pull/10570#issuecomment-3853842036
-
https://github.com/ghostty-org/ghostty/issues/1972#issuecomment-3859329233
-
https://github.com/ghostty-org/ghostty/issues/1972#issuecomment-3857881196
- **url: remove `,` from path_chars**
Related to #1972
Fixes an issue when paths have embedded comma, e.g.:
shared/src/foo/SomeItem.m:12, shared/src/
with path_chars greedily consuming the rest of the string.
Now file path matching stops at comma. Scheme URLs are unchanged and
still using the comma.
- **url: fix matching `~`, `$VAR`, `.directory/`**
Related to #1972
This commit adds three new alternatives for
`rooted_or_relative_path_prefix`:
- `~/`
- `$VAR` and
- `.local/`, `.config/` etc. for dot-prefixed directory names
Remaining commits fix edge cases one by one:
- **url: fix mid-string dot partial matches**
`"foo.local/share"` (was partial match) → now matches fully
- **url: fix $-numeric character matches**
`"$10/$20"` → no match
- **url: fix partial match of mid string $-variable**
`"foo/$BAR/baz"` (was partial match) → matches fully now
- **url: fix incomplete $-numeric behavior**
`"$10/bar.txt"` (was partial match) → but should not match at all
We were previously overwriting PS0 on every PROMPT_COMMAND. We now
append to PS0, but only if it doesn't already contain our hook.
This is also more consistent with the bash-preexec behavior we maintain
for older bash versions.
Paths like `./.config/ghostty:` and `./Downloads:` were incorrectly
including the trailing colon. Add a `no_trailing_colon` lookbehind to
all path branches and prevent space segments from starting after a colon
so that `": text"` is not consumed as part of the path.
When a user renames a surface via "Change Terminal Title" and then
uses copy_title_to_clipboard, the raw terminal title was copied
instead of the custom name.
This adds a new `copy_title` apprt action so each platform resolves
the effective title (user override or terminal-set) before copying
to clipboard.
Fixes#10345
We were previously overwriting PS0 on every PROMPT_COMMAND. We now
append to PS0, but only if it doesn't already contain our hook.
This is also more consistent with the bash-preexec behavior we maintain
for older bash versions.
The draw timer should only be activated in case a custom shader
is configured and the option custom-shader-animation is either always
or true. If the timer is kept alive CPU usage spiked enourmously.
Fixes#10667
This
$10/bar.txt
was partially matching but should not match at all.
This commit fixes this by simply `[\w]` to `[A-Za-z_]` as the first
character of a bare relative path, so digit-starting fragments can't
match.
Another option would be a lookbehind but I think the check above is much
simpler.
A string like this
foo/$BAR/baz
should match fully, not partially.
This commit fixes this by expanding `\$[A-Za-z_]\w*\/` to
`(?:[\w][\w\-.]*\/)*\$[A-Za-z_]\w*\/` in rooted_or_relative_path_prefix
so that we optionally eat everything before a variable `$VAR/`.
Strings like
$10/$20
Should not match.
This commit fixes this by narrowing `\w` after `$` to `[A-Za-z_]` which
is— according to Google Gemini— what environment variables can start
with.
A string like
foo.local/share
should match fully, not partially.
This commit fixes this by moving `dotted_path_lookahead` before
`bare_relative_path_prefix` so the dot-check scans the entire match
rather than only the text after it.
Related to #1972
This commit adds three new alternatives for
`rooted_or_relative_path_prefix`:
- `~/`
- `$VAR` and
- `.local/`, `.config/` etc. for dot-prefixed directory names
Related to #1972
Fixes an issue when paths have embedded comma, e.g.:
shared/src/foo/SomeItem.m:12, shared/src/
with path_chars greedily consuming the rest of the string.
Now file path matching stops at comma. Scheme URLs are unchanged and
still using the comma.
Break up the big monolithic URL and path regex into named sub-pattern
constants and compose the final expression from three commented
branches:
- URLs with a scheme
- absolute or dot-relative paths
- bare relative paths
This commit only breaks up the regex. It keeps the existing matching
behavior unchanged.
The `cursor` shell feature always used a blinking bar (beam), often to
the surprise of users who set `cursor-style-blink = false`.
This change extends our GHOSTTY_SHELL_FEATURES format to include either
`cursor:blink` (default) or `cursor:steady` based on cursor-style-blink
when the `cursor` feature is enabled, and all shell integrations have
been updated to use that additional information to choose the DECSCUSR
cursor value (5=blinking bar, 6=steady bar).
I also considered passing a DECSCUSR value in GHOSTTY_SHELL_FEATURES
(e.g. `cursor:5`). This mostly worked well, but zsh also needs the blink
state on its own for its block cursor. We also don't support any other
shell feature cursor configurability (e.g. the shape), so this was an
over generalization.
This does change the behavior for users who like the blinking bar in the
shell but have `cursor-blink-style = false` for other reasons. We could
provide additional `cursor` shell feature configurability, but I think
that's best left to a separate change.
The previous logic didn't detect the `e` option when it was combined
with other flags (e.g. `-ie`). This change also attempts to improve the
general readability of this code to be a bit more explicit.
bash-preexec implements support for its "precmd" and "preexec" hooks
using a combination of PROMPT_COMMAND and a DEBUG trap. The latter is
unfortunately quick slow (in a relative sense), and the overall system
is a bit more generalized than what we need for our shell integration
(e.g. supporting multiple function hooks, subshells, etc.).
Bash 4.4 introduced the PS0 variable, which is expanded and displayed by
interactive shells after reading a complete command but before executing
it. This is all we need to implement our own shell integration hooks.
In Bash 5.1, PROMPT_COMMAND can be an array variable, each element of
which can contain a command to be executed like a string PROMPT_COMMAND
variable. When adding our hook to PROMPT_COMMAND, we preserve its type
(string or array) to be minimally intrusive. This also matches direnv's
approach.
Bash 5.3 introduced support for function substitution, which is an even
more efficient way to run code from PS0, so we use that when available.
Otherwise, we use the more traditional command substitution approach.
Earlier versions of bash (such as 3.2, which still ships with macOS)
continue to use the bash-preexec path. This gives us two code paths to
maintain, but I think that's preferable to fully maintaining our own
DEBUG trap-based system for older bash versions given that bash-preexec
has proven to work reliably in those environments. We also wouldn't
unlock any other user benefits aside from removing the bash-preexec
script dependency.
See: #3724, #7734
PROMPT_COMMAND array support for introduced in bash 5.1, and it's the
preferred format moving forward. Using the string form is also fine, but
it's easy to be a modern bash citizen here, so let's do so.
bash-preexec implements support for its "precmd" and "preexec" hooks
using a combination of PROMPT_COMMAND and a DEBUG trap. The latter is
unfortunately quick slow (in a relative sense), and the overall system
is a bit more generalized than what we need for our shell integration
(e.g. supporting multiple function hooks, subshells, etc.).
Bash 4.4 introduced the PS0 variable, which is expanded and displayed by
interactive shells after reading a complete command but before executing
it. This is all we need to implement our own shell integration hooks.
In Bash 5.1, PROMPT_COMMAND can be an array variable, each element of
which can contain a command to be executed like a string PROMPT_COMMAND
variable. When adding our hook to PROMPT_COMMAND, we preserve its type
(string or array) to be minimally intrusive. This also matches direnv's
approach.
Bash 5.3 introduced support for function substitution, which is an even
more efficient way to run code from PS0, so we use that when available.
Otherwise, we use the more traditional command substitution approach.
Earlier versions of bash (such as 3.2, which still ships with macOS)
continue to use the bash-preexec path. This gives us two code paths to
maintain, but I think that's preferable to fully maintaining our own
DEBUG trap-based system for older bash versions given that bash-preexec
has proven to work reliably in those environments. We also wouldn't
unlock any other user benefits aside from removing the bash-preexec
script dependency.
See: #3724, #7734
The previous logic didn't detect the `e` option when it was combined
with other flags (e.g. `-ie`). This change also attempts to improve the
general readability of this code to be a bit more explicit.
This adds the ability to use two fingers on a touchpad to scroll left
or right on a Ghostty window to change tab pages. Uses the same basic
machinery as scrolling up and down the scrollback buffer. Scrolling
pages does not wrap around at the start or end of the tabs.
Related to #1972
The URL regex for file path detection requires paths to start with
`../`, `./`, or `/`. For bare relative paths like
`"src/config/url.zig"`, the regex could only match starting at the first
`/`, producing `"/config/url.zig"` as a result — always dropping the
first part of the path.
Fix: added a third top-level alternative to the regex. This matches bare
relative paths where:
1. The first component is word characters (possibly with dots/dashes):
`[\w][\w\-.]*\/`
2. The remaining path must contain a dot (via positive lookahead) — this
requires a file extension to avoid false positives on text like
input/output
3. Add a `(?<!\w)\/` instead of `\/` in the existing prefix group — the
standalone `/` prefix now requires that `/` is not preceded by a word
character. This prevents `"input/output"` from falsely matching
`"/output"`
Test cases added:
- src/config/url.zig → matches fully
- app/folder/file.rb:1 → matches with line number
- modified: src/config/url.zig → matches only the path part
- lib/ghostty/terminal.zig:42:10 → matches with line:col
- some-pkg/src/file.txt more text → stops before trailing text
- input/output and foo/bar → correctly do not match (no file extension)
The issue was nailed down here:
https://github.com/ghostty-org/ghostty/issues/1972#issuecomment-3845717672
