Closed robrecord closed 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.
Thank you @wez. I will try this out and report back.
🎉 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?
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.
I just started trying out wezterm's mux server over ssh, and commit 74da631 fixed this issue for me, thanks!
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.
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
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):
Mux server (not daemonized, bug not occurring):
GUI client (when Mux is daemonized, bug is occurring):
GUI client (Mux not daemonized, bug not occurring):
Screenshot of bug occurring:
Screenshot of bug not occurring:
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.