This isn't ideal, but it is better than previously: we would
close the window and before the Drop impl had updated the
list of known windows, we'd try to re-assign that window
to another mux window in a different workspace, but it would
never appear because the window was closed.
refs: https://github.com/wez/wezterm/issues/1531
Originally I had this the other way around but it was problematic
when considering things like maximized, font scaling and full screen
states.
refs: https://github.com/wez/wezterm/issues/1531
Rather than just quitting the app and potentially silently killing off
a number of panes that might be running in other workspaces, we now
will pick one of those workspaces and activate it.
refs: #1531
This action causes the active workspace for the gui to change.
If the name is omitted a random name will be generated.
If the workspace doesn't exist, it will be be created.
The optional spawn parameter can be used to launch a specific
program into the new workspace; if omitted, the default prog
will be used.
The gui only supports a single active workspace. Switching workspaces
will repurpose existing gui windows and re-assign them to windows
in the new workspace, adjusting their size to fit those windows,
spawning new windows or closing unused windows as required.
The gui now exits when there are no panes in the active workspace,
rather than no panes at all.
refs: #1531
This commit updates the last input time for the active client
id when calling into local pane. That time is visible in the
`wezterm cli list-clients` output.
The mux now has a notion of which client is actively doing things.
This allows, for example, newly spawned windows to take on the
active workspace for a given client.
The gui now assigns a client id on startup, and sets the active
workspace to `default`.
The mux server temporarily overrides the active id to that of
the currently dispatching client when processing PDUs.
refs: https://github.com/wez/wezterm/issues/1531
Tidies up some code duplication within the mux protocol handler.
Move some of the logic into Mux, remove legacy Spawn Pdu to reduce
more duplication.
I want to dedup some of the similar logic that exists in the gui
spawn implementation as well in a follow up.
The issue is that we work hard to match the keys pre-composition,
but for French and Norwegian layouts ALT-number are valid,
useful punctuation keys. It's awkward to make exceptions for
ALT keys when matching assignments, especially on macOS, and
the simplest thing to do is simply to remove the assignments
and leave it to our users to add their own if they want them.
The ctrl-shift and cmd based assignments are generally much
easier to keep, because those key combinations are not widely
used default mappings on any keyboard layout.
refs: #1543
refs: #1542
refs: https://github.com/wez/wezterm/pull/1132
This resolves some issues with non-US layouts (French, Norweigan)
where ALT-number are important and useful punctuation that we were
otherwise blocking.
This new behavior seems consistent with eg: vte terminals on linux
when switching to a French layout.
refs: #1543
refs: #1542
`ScrollByPage` can accept non-integer values in the configuration.
This allows fractional page scrolling, such as by half a page.
The default remains the same, at 1 page.
This is not exposed through any UX; the mux api allows setting
the workspace and propagating information about windows whose
workspace has changed.
Windows start with a blank workspace name.
This is just plumbing; nothing uses it yet.
refs: #1531
Define a way to compute a client ID and pass that through to the
mux server when verifying version compatibility.
Once associated, the session handler will keep some metadata
updated in the mux.
A new cli subcommand exposes the info:
```
; ./target/debug/wezterm cli list-clients
USER HOST PID CONNECTED IDLE WORKSPACE
wez mba.localdomain 52979 30.009225s 1.009225s
```
refs: #1531
This is a similar race condition to one we had before with the
multiplexer, where the connection UI made us think that we didn't
need to start a new process.
Additionally, the attach method would unconditionally create a
new client without checking whether we already had one.
In the case that the published symlink is stale, our default
client connection logic was to retry connecting with backoff
to give a newly spawned server a chance to startup.
In the context of a newly launched gui process checking to see
if an existing gui process can serve the same request, we don't
need to give it any grace: it will either answer immediately
or be deemed not useful.
This commit limits us to a single connection attempt in the case
where we're not automatically starting the server, which in turn
constrains the overhead to something in the order of microseconds
rather than nearly 0.5 seconds.
While we're in here, I noticed that if we thought we had a socket
to try and that failed, we'd always try to publish a new symlink.
However, if we failed due to mismatched version info, we shouldn't
publish over the top of the already running instance.
refs: #1529
user vars were stubbed out. This commit adds storage for them
in the mux client and adds a new notification that publishes each
var as it is changed. That differential stream is applied to the
storage in the mux client when it is received.
```lua
local wezterm = require 'wezterm'
wezterm.on("update-right-status", function(window, pane)
local woot = pane:get_user_vars().woot
window:set_right_status(tostring(woot))
end);
return {
unix_domains = {
{name="unix"},
},
}
```
then running:
* `wezterm connect unix`
* in that session: `printf "\033]1337;SetUserVar=%s=%s\007" woot `echo -n nice | base64``
causes `nice` to show in the status area.
refs: #1528
This is slightly misusing or misattributing things, but in
the context of the problem at hand, it is OK.
The issue is that palette changes are normally signalled by
the terminal instance in response to escape sequences. Those
changes are propagated to the mux client through the existing
alerting channel.
If the palette is changed implicitly via a config change, then
the terminal doesn't trigger that alert and the mux client(s)
don't know that they need to refresh the palette.
This commit tracks the last config generation per pane and
synthesizes a palette alert when it changes.
It might be better to have another variant of alert to indicate
config changes.
refs: #1526
This doesn't make a huge difference; I think we already addressed
the worst of the overhead with a combination of
eae327efcc
and the more recent commits to avoid over invalidation around
cursor movement and screen scrolling.
The numbers I see are a very small number of bytes per second when
scrolling through eg: vim and aren't crazy or alarming.
So I'm going to consider the related issue resolved!
closes: https://github.com/wez/wezterm/issues/867
