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!
The client domain stuff is now what I'd describe as almost
basically functional. It's not a great experience because
the latency is a bit high (it uses the coarse render data
as a proof of concept, and polls that every 100ms), and doesn't
connect the clipboard to the remote session. It also doesn't
enumerate and instantiate tabs for existing tabs on the remote
server, and doesn't have a way to gracefully detach from the
remote.
However, it is possible to connect and spawn tabs and interact
with them.
This removes some awkwardness in the impl by allowing casting
to a concrete implementation. This is a pattern I want to use
more widely and this diff proves the concept.
The idea is that we can use this to spawn a tab in a
specific domain. For example, "spawn tab in domain of current tab"
or "spawn tab in default domain".
