Setting the current surface's theme

[devshane]

I'm hoping to clarify a comment discussing themes and new windows: #2363 (reply in thread)

My use case is to set the theme in the current session before I ssh to a staging or production server and then revert it when the connection is closed. Other terms support this workflow with escape codes or shell integration.

Is this possible now? If not, is it a planned feature?

[jscheel]

This is a huge one for me. I have a script called prodmode that I use in other terminal emulators. It sets a bunch of env vars, asdf shims, and the session theme. This would be awesome to be able to do in ghostty.

[rhodes-b]

There is no way to programatically control ghostty right now, or have a theme in a specific situation besides it detecting system light mode and dark mode changes. Ghostty plans on having support to be programmatically controlled in the future refer to #2353 for more details on that

(besides editing an reloading the config)

[jscheel]

I think the specifics about this question have more to do with per-session configs, which is adjacent to the discussion about an api. But yeah, the other thread is definitely the place to follow for the dev of an api.

[rhodes-b]

I think the specifics about this question have more to do with per-session configs, which is adjacent to the discussion about an api. But yeah, the other thread is definitely the place to follow for the dev of an api.

Which also dont exist like listed in that discussion op linked.

Other terms support this workflow with escape codes

Kitty for example lets remote hosts change themes so it is related in that case

[00-kat]

There's an escape sequence to set the theme (OSC 4, 5, 6, 10-19, 104, 105, 106, 110-119, and there's also Kitty's extension which Ghostty also supports. I recommend using Kitty's extension as it's easier to use edit: use the former), which you could probably use as a workaround in your shell configuration or something. But as Bruce said, this is a duplicate of #2353.

As an example:

printf '\e]10;#FFFFFF\a'
printf '\e]11;#000000\a'
printf '\e]4;3=#5F5E2A;6=#227685\a'

Which can also be sent in a single printf:

printf '\e]10;#FFFFFF\a\e]11;#000000\a\e]4;3=#5F5E2A;6=#227685\a'

It is equivalent to the following configuration in the Ghostty config format is:

foreground = #FFFFFF
background = #000000
palette = 3=#5F5E2A
palette = 6=#227685

Note: this post was edited to switch from using the Kitty extension to XTerm's smattering of OSC sequences; see the comments under this post for the reason. You can find the old example in the edit history.

[devshane]

When I paste that printf example at a zsh (or bash) prompt, the colors are changed correctly but I see control characters printed and "21" is added to the keyboard buffer as if I'd typed it:

bash-3.2$ printf '\033]21;foreground=#FFFFFF;background=#000000;3=#5F5E2A;6=#227685\e\\'
^[]21^[\bash-3.2$ 21

It doesn't seem like ghostty is "eating" the kitty escape sequences. When I use OSC sequences, say for just the background color (11), it operates as I'd expect. For example, this changes the background to bright green without any outputted characters or keyboard buffer input:

bash-3.2$ printf '\033]11;#00ff00\007'
bash-3.2$

The alternative ST sequence also works:

bash-3.2$ printf '\033]11;#0000ff\e\\'
bash-3.2$

Thanks for the help, it's appreciated! This is very close to what I need atm.

[00-kat]

Hmm, odd. I had tried out my printf in Fish, but in Bash I can see odd behaviour when I use it too.

It looks like Ghostty is sending the following in response to that OSC: \033]21\033\\ (i.e. OSC 21 ST), which Kitty doesn't do. The spec doesn't specify whether responding with nothing in the presence of no query is allowed, and it looks like Ghostty does; I'll ask around but for now I'll update my comment to use the XTerm set of sequences.

[00-kat]

Will be fixed with #5770.