@chipsenkbeil: I spotted a latent bug in here that got fixed as
a side effect of this change. For `write_file` and possibly others,
reply.try_send was only called in the case where file_id was valid.
For an invalid id, I think the caller could hang.
Not sure if this was a problem in practice, but I wonder if it might
have contributed to some of the weird state issues you mentioned.
This works, but on macOS, there is a segfault in openssl when the
session is closed... I'm going to try this on Linux to see if it
is consistent behavior and ponder next steps.
The issue here is that when spawning a new tab in the mux client,
we didn't record the local/remote tab id mapping.
Subsequently, when processing the overall list of tabs, we'd realize
that the mapping was missing and allocate a new local tab to act
as the holder for the existing remote tab and end up with a strange
aliased view of the tab in a second tab!
This commit establishes that mapping at the time that we spawn
the new pane.
refs: https://github.com/wez/wezterm/issues/1222
The first problem in #1222 is that the environment in the spawned
mux server has inherited the unix socket path from the GUI that
is the client, rather than the mux server.
That means that `wezterm cli` is operating on the mux namespace
of the client (which is a layered/wrapped view of the mux server),
rather than the mux server.
This fixes `wezterm cli split-pane` in the case where unix domains
are in use together with `connect_automatically = true`, although
there is still a really weird issue with tabs that needs to be
run down.
refs: https://github.com/wez/wezterm/issues/1225 (sort of)
refs: https://github.com/wez/wezterm/issues/1222
The port number is guaranteed to be set in the config parser,
just like for the host and user, so the unwrap is "OK", but it's
less brittle to handle the error consistent with the others here.
A user reported a problem matching `等距更纱黑体 SC` against
a font that wezterm thought was really named `Sarasa Mono SC`.
This commit attempts to match against other language names,
although the Sarasa font that I found on the MS store doesn't
return `等距更纱黑体` in any of the additional SFNT name tables,
so this isn't a successful change.
