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.
When using client-side decorations, we can now skip rendering
the header/title bar.
If you've set NONE decorations, then wezterm will configure
the window that way, but that is only respected when the window
is created, as weston crashed when I tried to change this in
a window config reload event.
The wayland frame now also observes config change events,
so frame color adjustments should now take effect without
restarting.
refs: #1077
Since we may have two different sizes/namespaces of fonts between
the title font and the main terminal font, we need to be a bit more
careful to pass down distinguishing font information when caching
glyphs.
In addition, I noticed that the advance for custom block glyphs
(eg: powerline!) weren't right in the tab bar. To resolve this,
when shaping, we skip using the glyph from the font and synthesize
a placeholder with the appropriate advance.
Was mistakenly trying to use the windows font because of negative logic.
Tidy up, and prefer the gnome default theme font (Cantarell), but fall
back to DejaVu Sans.
