wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.64k stars 788 forks source link

Colour scheme is not honoured using unix domain multiplexer if daemonized #3397

Closed robrecord closed 1 year ago

robrecord commented 1 year ago

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20230327-213829-cb5252a2

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Even when feeding the correct configuration for colour scheme to the multiplexer, the connecting gui client has the default colour scheme. This seems only to happen after the mux server is daemonized.

To Reproduce

pkill wezterm-mux-server

wezterm-mux-server --skip-config \
--config 'color_scheme="Gruvbox Light"' \
--config 'unix_domains = {{name="test"}}' \
--daemonize

wezterm --skip-config \
--config 'color_scheme="Gruvbox Light"' \
--config 'unix_domains = {{name="test"}}' \
connect test

This creates a window, incorrectly using the default color scheme.

Configuration

no config

Expected Behavior

The configured colour scheme is used.

Logs

Mux server (daemonized, bug is occurring):

11:13:47.146  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:13:47.146  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:13:47.150  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:13:47.150  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:13:47.193  DEBUG  config         > Reloaded configuration! generation=1
11:13:47.240  WARN   wezterm_term::terminalstate::performer > Unhandled OSC  1337 RemoteHost=user@hostname
11:13:47.240  WARN   wezterm_term::terminalstate::performer > Unhandled OSC  1337 ShellIntegrationVersion=12 shell=zsh
11:13:47.240  WARN   wezterm_term::terminalstate::performer > Unhandled OSC  1337 RemoteHost=user@hostname
11:13:47.670  WARN   wezterm_term::terminalstate::performer > Unhandled OSC  1337 RemoteHost=user@hostname.local

Mux server (not daemonized, bug not occurring):

10:57:21.370  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
10:57:21.370  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
10:57:21.374  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
10:57:21.374  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
10:57:21.416  DEBUG  config         > Reloaded configuration! generation=1

GUI client (when Mux is daemonized, bug is occurring):

11:04:50.320  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:04:50.320  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:04:50.324  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:04:50.324  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:04:50.366  DEBUG  config         > Reloaded configuration! generation=1
11:04:50.390  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:04:50.390  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:04:50.393  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:04:50.393  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:04:50.433  DEBUG  config         > Reloaded configuration! generation=1
11:04:50.519  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:04:50.519  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:04:50.523  DEBUG  config         > Reloaded configuration! generation=2

GUI client (Mux not daemonized, bug not occurring):

11:03:46.416  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:03:46.416  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:03:46.420  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:03:46.420  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:03:46.463  DEBUG  config         > Reloaded configuration! generation=1
11:03:46.487  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:03:46.487  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:03:46.491  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:03:46.491  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:03:46.530  DEBUG  config         > Reloaded configuration! generation=1
11:03:46.612  DEBUG  config::config > Apply color_scheme="Gruvbox Light" to config
11:03:46.612  DEBUG  config::config > Apply unix_domains={{name="test"}} to config
11:03:46.616  DEBUG  config         > Reloaded configuration! generation=2

Screenshot of bug occurring:

Screenshot 2023-03-29 at 11 17 11

Screenshot of bug not occurring:

Screenshot 2023-03-29 at 11 14 21

Anything else?

Interestingly, if the mux process is not daemonized, (and the GUI is started from a different terminal window), it works - the bug is not there.

Using my own config I have seen that doing a oneliner of the above commands, with daemonization, the color scheme works - but introducing a sleep 1 between the mux and client commands, or typing the commands on separate lines, allows the bug to occur. This is 100% reproduceable usibg my config, but I can't reproduce this "oneliner" behaviour with the stripped down config used above, which causes me to think the processing time (my config is quite long) allows the GUI to connect before the bug "happens".

From all of the above, it seems something in the daemonization process is causing the issue.

wez commented 1 year ago

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

robrecord commented 1 year ago

Thank you @wez. I will try this out and report back.

robrecord commented 1 year ago

🎉 I can confirm it works using the above nightly, and the test case supplied in this issue now works correctly - thanks!

However this change in itself did not fix the original issue I was having, using my saved configuration. I'll check the latest nightly and could address that in another ticket if necessary. Shall I close this issue now or leave it?

robrecord commented 1 year ago

Confirmed that 338174b does not seem to fix my underlying problem.

I will close this issue and reopen with a new test case to reproduce my issue.

EDIT: fixed in latest nightly.

aaronkollasch commented 1 year ago

I just started trying out wezterm's mux server over ssh, and commit 74da631 fixed this issue for me, thanks!

github-actions[bot] commented 1 year ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.