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