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.
We were truncating the right-status text because we were passing
the padded number of cols for the tab bar, but since the tab bar
now exists outside the padding, that value was too small.
This commit introduces the `Dimension` type which allows specifying
a value in a variety of units; pixels, points, cells, percent.
`Dimension` needs contextual information to be evaluated as pixel
values, which makes resolving the value from the config slightly
more of a chore.
However, this type allows more flexible configurations that scale
with the font size and display dpi.
refs: #1124, #291, #195
The previous commit was partially OK, but the main cause of
emoji being wonky was this bit of macos specific code that I
added ages ago.
Remove that hack and the portion of the code from the previous
commit that was working to undo it.
This should make the baselines consistent across all platforms.
refs: #1203
