Open Lenbok opened 1 year ago
Hey, I just found this issue and I can confirm that it is still a problem.
The code in SwitchToWorkspace seems to fail when the spawn is in a remote domain. So the final line in this snippet:
let switcher = crate::frontend::WorkspaceSwitcher::new(&name);
mux.set_active_workspace(&name);
if mux.iter_windows_in_workspace(&name).is_empty() {
Fails to find any windows in the workspace, because the test is run before the actual connection to the remote server has completed. And a new window is mistakenly created.
This also means that there is no way to attach to an already running remote mux server, without also spawning a new process at the same time. It would be nice to attach to the remote server and not have to kill a spurious shell.
Disclaimer: I have no experience with Rust, so this might be wrong. Just hoping it might be a useful clue for someone who knows what they're doing.
Solved my local problem and posting it here for whatever value, if any, it might offer others...
function switch_to_domain(dom, window, pane)
local ws={name=dom, spawn={domain={DomainName=dom}}}
local action=wezterm.action{SwitchToWorkspace=ws}
window:perform_action(action, pane)
end
function toggle_domain(dom, window, pane)
if window:active_workspace() == dom
then
switch_to_domain("default", window, pane)
else
wezterm.mux.get_domain(dom):attach()
switch_to_domain(dom, window, pane)
end
end
function toggle_domain_action(dom)
return wezterm.action_callback(
function(win, pane)
toggle_domain(dom, win, pane)
end
)
end
and then:
{key="k", mods="CTRL|SHIFT", action=toggle_domain_action("kia")},
{key="o", mods="CTRL|SHIFT", action=toggle_domain_action("ox")},
Creating two keys: "k" which toggles the "kia" ssh domain, and "o" which toggles the "ox" ssh domain. A workspace, the same name as the domain is created if it doesn't already exist. If the workspace already exists and is the current workspace, those keystrokes instead toggle to the default workspace.
Probably the only potential clue is the line :
wezterm.mux.get_domain(dom):attach()
Which attaches the domain first, before attempting to switch to it. This removes the spurious window that I was seeing here. But I fear it might be a slightly different problem than others were reporting above.
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
xfce
WezTerm version
wezterm 20230119-074737-730c41b7
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
When switching to a new workspace, sometimes wezterm uses the existing window, and sometimes it doesn't and opens a new window (leaving the old one present). It should always re-use the existing window. When closing one of the workspace windows, sometimes it closes, and sometimes it immediately re-opens another window.
To Reproduce
Ensure no wezterm (or mux server) is already running, then start with the provided config:
$ wezterm-nightly --config-file wezterm.lua
You'll get one window, on a workspace named after the current host. I think it's on the local domain.
At this point a brand new window appears - it should have re-used the existing window. Both windows are on the just selected workspace.
Configuration
Expected Behavior
It should have re-used the existing window.
Logs
No response
Anything else?
No response