This extracts all our image renderer state into a separate struct,
blandly named `renderer.image.State`. This structure owns all the
storage of images and placements and exposes a limited public API to
manage them.
One motivation was to limit state access by our Kitty graphics functions
within the generic renderer. Another was to limit our own generic
renderer from getting our image system into an incoherent state. This is
prevented now on both sides due to some encapsulation.
This currently only supports Kitty images, since that's the only image
protocol we support. But I intend to add additional image types to this,
namely the ability to add overlay images for debug information. **There
are no plans to add new image protocols to the terminal,** the
extraction is purely to support some internal features. But, it could be
used for other protocols one day.
This extracts all our image renderer state into a separate struct,
blandly named `renderer.image.State`. This structure owns all the
storage of images and placements and exposes a limited public API
to manage them.
One motivation was to limit state access by our Kitty graphics functions
within the generic renderer. Another was to limit our own generic
renderer from getting our image system into an incoherent state. This is
prevented now on both sides due to some encapsulation.
This currently only supports Kitty images, since that's the only image
protocol we support. But I intend to add additional image types to this,
namely the ability to add overlay images for debug information.
**There are no plans to add new image protocols to the terminal,** the
extraction is purely to support some internal features. But, it could be
used for other protocols one day.
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.
Closes#7877.
Small disclaimer: First Ghostty PR and Zig PR, but looking forward to
contributing to the project.
This PR supports shell-integration-features `ssh-env` and `ssh-terminfo`
as per other shells, but not the rest as this is what the issue states.
That being said, with this PR, then you would see this:
- `warning(io_exec): shell could not be detected, no automatic shell
integration will be injected`, but given that the default mode is
`detect` it will pick up the executable and if ssh features are enabled
it will integrate it. This might be confusing for users.
- I decided to not add `nu` to `pub const Shell` because if we do so,
then from what I understand from the code, then the code flow would
imply that "shell integration will be injected" but it will only do so
if those `ssh-*` features are enabled, which may be misleading. But on
the other hand, providing `ssh` shell integration but returning `null`
for `?!ShellIntegration` does not seem very correct either.
- I dont like that I added `features` argument to `setupshell`, just to
check them if `nu` was used. The reasoning is because the way Nushell
works, if we autoload the `nushell` directory (by `setupXdgDatadirs()`)
even if no `ssh` features were present, it will wrap the `ssh` function
and I think that is not desirable, even if we end up just forwarding the
arguments.
Sorry for the long wall of text, but I think it was worth to add some of
the doubts I have had myself, plus the ones that you folks may add. I am
very happy to iterate on this, even if its a very "Easy" one, so I much
welcome the feedback.
> [!NOTE]
>
> Used `GPT` for helping with nushell variable naming
verification/improvement
> Used `Gemini` for helping with understanding the `Zsh` ssh integration
so that I could replicate the logic with nushell. Just because I find
`zsh` language very difficult to understand in detail.
This changes our OSC133 parser to parse options lazily. We do this for
multiple reasons:
1. Parsing all our options ahead of time balloons our required
osc.Command tagged union type which has C ABI implications. Adding
all supported options (including Kitty extensions) today already
breaks our C ABI.
2. Invalid options are allowed by the specification and should be
explicitly ignored, so we don't need to validate options at all
during parse time.
3. Semantic prompt markers don't need to be high throughput, so we
can afford to do some extra work at processing time to gather
the options. They're also rather short usually.
Related to #5932
This updates our OSC parser to parse the full OSC 133 specification:
https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md
The logic for handling these events was _unchanged_ from our prior
implementation. This is just a parser-only update. As such, we ignore a
bunch of semantic prompt command we should definitely handle, and
incorrectly handle others. This is the crux of #5932 that I want to head
towards fixing. This PR just contains the parser updates.
I also retained all the Kitty parser extensions.
**AI disclosure:** AI helped a lot of the rote tasks once I manually did
a few. I'm still reviewing this manually but will do so shortly.
