We always add GHOSTTY_SHELL_INTEGRATION_XDG_DIR to XDG_DATA_DIRS with a
tailing colon (via our prependEnv routine), so we can greatly simplify
this cleanup code with a single str:replace call.
We always add GHOSTTY_SHELL_INTEGRATION_XDG_DIR to XDG_DATA_DIRS with a
tailing colon (via our prependEnv routine), so we can greatly simplify
this cleanup code with a single str:replace call.
Related to #1966
This adds support for OSC133 `cl=line` (single line movement with
left/right arrow keys) and modifies our bash and zsh shell integration
to advertise support for it. With this, bash and zsh both support click
to move at the prompt without any modifiers:
https://github.com/user-attachments/assets/7f6cb0b8-390c-4136-8c25-059b21b138c5
This also removes our legacy `promptPath` and related functionality
(pressing alt) since this is superior and there's no reason to keep that
around.
Fixes#10522
This also fixes possible runtime safety crashes. Whenever the underlying
size information doesn't match what our renderer or grid see, then we
should deinit and reinit.
Fixes#10522
This also fixes possible runtime safety crashes. Whenever the underlying
size information doesn't match what our renderer or grid see, then we
should deinit and reinit.
This adds support for the `OSC 133 A click_events=1` extension
introduced by Kitty and supported by Fish.[^1]
**What this means:** If the shell advertises `click_events=1` support,
Ghostty will _unconditionally_ (no modifier required) send mouse events
to the shell for clicks on a prompt line, delegating to the supporting
shell to move the cursor as needed. For Fish 4.1+ this means that
clicking on the prompt line moves the cursor (see demo video below).
This PR also contains:
* A minor fix in `cl` parsing but we don't yet implement the logic there
* Updated inspector to show the semantic prompt click mode
## Demo
https://github.com/user-attachments/assets/03ef8975-7ad9-441f-aaa2-9d0eb5c5e36d
## Implementation Details
`click_events` is wildly underspecified, so here are the details the
best I understand them. This itself is not a specification (I omit
details) but adds some more context to it.
The `click_events=1` option can be specified with `OSC 133 A` (Ghostty
also allows it on OSC 133 N). When that is specified, it flags for all
future prompts that the screen supports click events for semantic
prompts. If both `click_events` and `cl` are specified, `click_events`
takes priority if true. If `click_events=0` (disable), then any set `cl`
will take priority.
When a mouse click comes in, we check for the following conditions:
1. The screen supports click events
2. The screen cursor is currently at a prompt
3. The mouse click was at or below the starting prompt line of the
current prompt
If those are met, we encode an SGR mouse event with: left button, press,
coordinates of click. It is up to the shell after that to handle it. Out
of prompt bounds SGR events are possible (specifically below). The shell
should robustly handle this.
[^1]: I don't know any other terminal or shell that supports it at the
moment.
Wrapping `use ghostty-integration` in a `try .. catch` here makes this
suggestion more resilient to environments where we didn't inject our
resource directory into XDG_DATA_DIRS (but are still running Ghostty).
The ssh wrapper previously used a separate set_ssh_terminfo function
that returned a record to be merged, which result in some redundant
control flow and TERM assignments.
This inlines the terminfo logic and builds env/opts incrementally based
on feature flags. TERM is set to a fallback early and only overridden on
success, which simplifies our error handling and avoids mutable variable
capture issues in closures.
Lastly, warnings are now consistently written to stderr, and I made
various other control flow and syntax improvements.
Wrapping `use ghostty-integration` in a `try .. catch` here makes this
suggestion more resilient to environments where we didn't inject our
resource directory into XDG_DATA_DIRS (but are still running Ghostty).
This reporting shouldn't have been tied to the 'title' shell features.
That's a different feature where we change the window title (icon) to
reflect the current command using OSC 2.
This reporting shouldn't have been tied to the 'title' shell features.
That's a different feature where we change the window title (icon) to
reflect the current command using OSC 2.
Bumps
[namespacelabs/nscloud-setup-buildx-action](https://github.com/namespacelabs/nscloud-setup-buildx-action)
from 0.0.21 to 0.0.22.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="f5814dcf37"><code>f5814dc</code></a>
Add tag input for named builder selection (<a
href="https://redirect.github.com/namespacelabs/nscloud-setup-buildx-action/issues/14">#14</a>)</li>
<li><a
href="a204134a6b"><code>a204134</code></a>
build(deps): bump lodash from 4.17.21 to 4.17.23 (<a
href="https://redirect.github.com/namespacelabs/nscloud-setup-buildx-action/issues/13">#13</a>)</li>
<li>See full diff in <a
href="a7e5254161...f5814dcf37">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Fixes#10524
This changes our inspector from being renderer-change driven to being
FPS driven. Both macOS and GTK now draw the inspector at most at 30 FPS
on a timer. Details between platforms are slightly different and covered
later.
The motivation for this is that triggering an inspector redraw on frame
update was causing _too many_ draws, leading to high CPU usage. Further,
terminal change isn't a good proxy for all the state that the inspector
shows, and tracking changes to all those to trigger a redraw is just a
lot of complexity.
Instead, moving to a standard, game-like framerate driven redraw
simplifies a lot. It does cost some CPU when idle, but actually lowers
our CPU under normal usage since it's rendering less often (30 FPS isn't
much for what we're doing).
**For macOS,** this uses CADisplayLink, so the refresh rate is variable.
I've seen macOS drop it to 1fps when there isn't much happening, which
is nice. We also setup an occlusion event so when the window is fully
occluded we stop rendering entirely.
**For GTK,** the tools to control this are limited. We do a standard
max-30 FPS tick redraw but can't support occlusion beyond what the
window server supports. For Wayland, I believe we get it for free
(occluded windows aren't drawn).
Fixes#5932
This updates our core terminal internals to track [semantic prompts
(OSC133)](https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md)
in a way that can enable us to fully implement the specification. This
PR makes our terminal state fully handle all specified sequences
properly, but we still ignore some noted options (`aid`, `cl`, etc.)
that are not critical to functionality.
I took a look at our shell integrations and they should still be
accurate and correct with regards to their OSC133 usage.
This doesn't introduce any new functionality, but should result in
existing functionality being more correct, more robust, and gives us the
groundwork to do more with semantic prompts in the future.
> [!NOTE]
>
> This PR description is **fully human written.** I realize its layout
and use of headers may trigger AI smells. But it's all me, I promise. :)
## Extensions
I kept support for the Kitty `redraw=0` extension: if an OSC133A command
sets `redraw=0` then we will NOT clear the prompt on resize (assuming
the shell can NOT redraw the prompt). I don't actually know any scripts
that utilize this, so we may want to just throw it away, but we had
support before and it's cheap to keep around and it's tested.
## Limitations, Missing Features
* We don't currently respect `aid` so nested semantic zones can break
things. This would require significant rework since aids are arbitrary
strings. It'd require managed memory on pages to store the aids. Fwiw,
in my brief survey of popular mainstream terminals, I wasn't able to
find any that respect this. Maybe Warp does since semantic prompts are
so core to their product but its not OSS for me to verify.
## Internal Changes
### `terminal.Page`
The internal state now tracks the current _semantic content type_ via a
2-bit flag on each `Cell`:
* `output` (zero value) - Command output
* `input` - Prompt input, typed by the user
* `prompt` - Prompt itself, e.g. `user@host $`
In addition to this, each `Row` also has a 2-bit flag. This flag _only
tracks if the row might contain a prompt_:
* `no_prompt` (zero value) - No prompt cells
* `prompt` - Prompt cells exist and this started the prompt (OSC133 A)
* `prompt_continuation` - Prompt cells exist and this continued a prior
prompt (OSC 133 A `k=s` or `k=c`)
The row flags server two functions:
1. An optimization to make prompt scanning faster
2. The only place the existence of continuation vs primary prompt is
stored since cells themselves only store `prompt`
### `terminal.PageList`
The PageList has two new functions:
* `promptIterator` - An iterator that yields `Pin` values that map to
the _first line_ of a prompt.
* `highlightSemanticContent` - Returns a highlight (pin range) to map to
specific semantic content for a given prompt pin. This lets you quickly
grab stuff like the prompt lines, content lines, etc.
### `terminal.Screen`
* The Screen now has a flag that tracks whether we've seen any row
trigger a semantic prompt. This can be used as a fast path to avoid
expensive semantic prompt operations if we know our screen can't
possibly contain any. We don't currently use this but I plan to.
* **Big one: clearing the prompt lines is now built-in to resize.** This
makes our resize aware of semantic prompts which makes it work _so much
better_ already.
### `terminal.Terminal`
* A new function `semanticPrompt` for handling all the semantic prompt
operations.
**AI Disclosure:** AI was used in various ways throughout this. It is by
no means 100% AI-written, it's mostly human written. I reviewed
everything. AI was used mostly for some assistance on rote tasks.
Nu properly marks input areas with OSC 133 B, but if it spans multiple
lines it doesn't mark the continuation lines with the k=s sequence.
Our prompt redraw logic before only cleared explicitly designated prompt
lines. But if the input line is multi-line and the continuation lines
are not marked, those lines would not be cleared, leading to visual
issues on resize.
To workaround this, we assume that if the current cursor semantic
content is anything other than "command output" (default), then we're
probably at a prompt line and should clear from there all the way up.
This works around Fish (at least v4.2) having a non-compliant OSC133
implementation paired with not having the hooks to fix this via shell
integration. We have to instead resort to heuristics in the terminal
emulator. Womp, womp.
The issue is that Fish does not emit OSC133 secondary prompt (`k=s`)
markers at the beginning of continuation lines. And, since Fish doesn't
provide a PS2-equivalent, we can't do this via shell integration.
We fix this by assuming on newline (`\n`) that a cursor that is already
painting prompt cells is continuing a prior prompt line, and
pre-emptively mark it as a prompt line. But this has two further issues
we have to work around:
1. Newline/index (`\n`) is one of the _hottest path_ functions in
terminal emulation. It sucks to add any new conditional logic here.
We do our best to gate this on unlikely conditions that the branch
predictor can easily optimize away.
2. Fish also emits these for auto-complete hints that may be deleted
later. So, we also have to handle the scenario where a prompt is
continued, then replaced by command output, and fix up the prompt
continuation flag to go back to output mode.
Point 2 is ALMOST automatically handled, because Fish does emit a `CSI J`
(erase display below) to erase the auto-complete hint. This resets all
our rows back to output rows. **Unfortunately**, Fish emits `\n` before
triggering the preexec hooks which set OSC133C. So we get the newline
logic FIRST (sets the prompt line), THEN sets the output cursor. If they
switched ordering here everything would just work (with the one
heuristic). But now, we need two!
To address this, I put some extra heuristic logic in the OSC133C
(output starting) handler: if our row is marked as a prompt AND our
cursor is at x=0, we assume that the prompt continuation was deleted
and we unmark it.
I put the heuristic logic dependent on OSC133C because that's way colder
of a path than putting something in `printCell` (which is the actual
hottest path in Ghostty).
We could get more rigorous here by also checking if every cell is empty
but that doesn't seem to be necessary at this time for any Fish version
I've tested. I hope thats correct.
I'd really love for Fish to improve their OSC133 implementation to
conform more closely to the terminal-wg spec, but we're going to need
these workarounds indefinitely to handle older Fish versions anyway.
Insert OSC 133 A k=s marks after each newline in PS1, so that all lines
following the first are marked as secondary prompts. This prevents ghostty
from erasing leading lines during terminal resize.
