Closed Lenbok closed 1 year ago
(Also weirdly, when I clicked the close button on on of the GUI terminals, it immediately opened a new one, I think into a different workspace)
This is improved by 39bb8b3f3943cb02aa723fb41c6a55e0195bebbc but I don't know if that's covered everything that you were seeing. Please give that a go and let me know!
It should show up as an AppImage build ~30 minutes from now.
I'm excited! I'll check it out tomorrow, thanks!
Checking this out now. Since I last updated it's not happy with my workspace keybindings. I have entries like:
{ key = "W", mods = "LEADER", action = wezterm.action{SwitchToWorkspace = {name = "WORK"}}},
And wezterm is complaining:
callback error
stack traceback:
[C]: in function 'wezterm.action'
[string "/home2/len/.config/wezterm/wezterm.lua"]:230: in main chunk
caused by: error converting Lua table to KeyAssignment (Error processing
SwitchToWorkspace::spawn: missing field)
I thought spawn was optional?
For now I've worked around by adding spawn = {}
to the SwitchToWorkspace parameters.
In terms of keeping the windows / workspaces straight it seems to be working much better (I've only been testing a unix domain, haven't tried ssh yet). A couple of remaining issues:
Related to workspace handling, but not directly related to this bugfix:
https://github.com/wez/wezterm/commit/94039c473bebbf35d4994863965ebd58c3647218 should fix the spawn optional field issue.
- If I click on the OS window close button, the window immediately re-opens containing all workspaces except the one that was open at the time the window was closed. I would expect that the window would stay gone.
Hmm, the current behavior comes from before we had a formal detach action. The gui currently requires that there be at least 1 window open, because there's no way to interact after the last one closes. It picks a workspace from the remaining workspaces and adopts that for the window. The close logic doesn't (easily) know whether all the panes are remote/detachable or whether you might lose/forget some.
When closing the window in this situation, would you prefer that it detach completely and quit? What do you think should happen if (in the future) a window/workspace pair has a mixture of local and remote panes, and that pair is not currently active in the window?
- For some reason, mouse clicking on the tabs within the window is often super laggy (like a few seconds) between the click and the tab view changing. Switching tabs via key binds is fast.
Weird!
Related to workspace handling, but not directly related to this bugfix:
- Is there a config setting to change the name of the default workspace?
- Is there a way to have SwitchToWorkspace prompt for a workspace name?
Not currently.
When closing the window in this situation, would you prefer that it detach completely and quit? What do you think should happen if (in the future) a window/workspace pair has a mixture of local and remote panes, and that pair is not currently active in the window?
Yes, I think so. I want that window gone (e.g. finished for the day, need to reboot the local PC, etc), but will want to reattach at some point in the future.
But maybe I also have tmux brain damage. I never have mixtures of local and remote panes within a workspace. Or even remote domains - if I need panes on another host for that project they are by ssh'ing from the "base domain", rather than directly as their own domain from my local pc (as that would mean duplicating ssh setup for those extra hosts onto multiple machines). I don't even know what it would mean to have a workspace containing panes from different native domains - it seems like you couldn't connect/attach to that workspace (aka project) from another machine and have the same set of panes all available.
I also don't have workspaces from different domains within the same GUI window (really since it's not possible in tmux-land without nesting sessions, with all the leader key gymnastics that involves). Currently I "switch domains" by selecting a different gui window).
Would be interested to hear other people's workflows.
I'm going to close this out as there are now solutions to all of the things mentioned in this thread in main
:
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?
Linux X11
WezTerm version
wezterm 20220511-182551-566b58a6
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
I'm trying to reproduce my tmux workflow, and it seems I'm hitting some bugs. I normally have tmux running on my office workstation, and inside it I have several sessions (one per client/project), and each session has a bunch of (tmux) windows related to it. I can attach to that tmux from any number of graphical terminals, whether they be local to the office, or remote via ssh when I WFH.
With wezterm I'm getting multiple windows opening when I try to connect to an existing ssh domain and/or switch workspaces.
To Reproduce
I axed off any wezterm mux server and clients on my work and home pc, and installed the latest appimage on both.
From a non-wezterm on my home pc I ran
wezterm connect noir
(thats' an ssh domain for my work pc). It gave me a new GUI with just a default workspace. I then SwitchToWorkspace'd a couple of different workspaces (sayA
andB
, plus the originaldefault
) and created some number of tabs in each and did some differentls
es to differentiate them.Now back on the non-wezterm on my home pc I ran
wezterm connect noir
again. It popped up a two new GUIs:default
(showingB
contents) andA
default
andA
In this latter GUI window ISwitchToWorkspace
A
and that GUI window disappeared completely and the other GUI window swapped to the actualA
workspace. In that GUI ISwitchToWorkspace
default
and the GUI that had previously gone reappeared.Configuration
Expected Behavior
tmux-like behaviour, allowing multiple views into the same workspace configurations.
Logs
No response
Anything else?
No response