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.
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.
