Problem scenario was:
* spawn a window
* resize it larger
* spawn a new tab
When working with a mux client tab, the surface size in the new tab
didn't reflect the size of the remote surface, so the rendering was
messed up.
Arrange to know the size up front.
Repeated moves or wheel events are collapsed so that we don't clog up
the queue. The queue size doesn't matter as much as the latency of
processing a large queue. For fast or repeated moves the queue can grow
rather quickly, and with what is currently ~25-50 ms round trip per
entry for a remote session, that is a poor UX.
The latency is not great, and there are more authentication and
authorization features that need to be added, but this shows that
we can connect and talk to a remote muxer.
It's taking a while for https://github.com/jwilm/vte/pull/20 to get
merged, so point to my branch directly while I build out some
tunneled mux protocol escape sequences.
I'll need to fork vte on crates.io if vte doesn't merge the PR
before the next termwiz crate bump.
This do_paint call was added in 8995974124
but I don't think it was intentional; it looks like an accidental commit
of something during debugging.
The intent is that we tick over and paint every tick (~50ms) and this
behavior here was causing us to paint after every input event, which is
undesirable when processing the selection.
refs: https://github.com/wez/wezterm/issues/33
When using WSL, we want to place the unix socket on NTFS and that
reports an insecure set of permissions which cause us to refuse
to start up.
As a bit of a gross hack, allow skipping that check by setting an
environmental variable:
```
WEZTERM_SKIP_MUX_SOCK_PERMISSIONS_CHECK= wezterm start --front-end muxserver
```
that works best in conjunction with this in the WSL `.wezterm.toml`
file: (swap `wez` with your username):
```
mux_server_unix_domain_socket_path = "/mnt/c/Users/wez/.local/share/wezterm/sock"
```
refs: https://github.com/wez/wezterm/issues/33
spawn now requires that the window_id be passed in; this makes it
a bit easier to spawn a remote tab into an existing window.
As part of this, beef up how we manage the window/tab association.
The Domain::spawn interface needs to be adjusted to allow indicating
which window we want to spawn into, or whether the spawn should
create a new window, but aside from that, we can now attach to
a mux server and instantiate tabs and windows!
