After killing the remote pane, we no longer trigger the renderable
poll stuff that would detect that the pane was dead.
Let's speculatively set it to dead so that we don't get stuck with
stray tabs/panes.
https://github.com/wez/wezterm/issues/1752
There were a a couple of issues:
* `ImageData::hash` would re-hash the image on every call, and this was
called for every cell that comprised an image on the mux server side
* `SerializedLine` needed to understand how to remove the `Arc<ImageData>`
image attachments so that we didn't serialize a complete copy of the
image per cell that comprised the image.
A new RPC was introduced to attempt to fetch `ImageData` given its
content hash and pane, row and cell index as a hint to locate it.
A client side LRU of content hash to `ImageData` is used to avoid
issuing repeat calls to that new RPC.
refs: #1237
The broot icon font has glyphs with horizontal advance set to 0. That
would cause us to consider the glyph to be zero width, so handle that as
a special case. Note that it is legit for certain cells to end up with
a zero advance/width during shaping if they represent combining
characters: this is more common in Arabic scripts.
refs: https://github.com/wez/wezterm/issues/1787
The condition should be: dpi-changed && (close-enough-stuff)
but was (dpi-changed && (some-close-enough-stuff)) ||
(other-close-enough-stuff).
The net result was toggling non-native full screen on macos could
falsely try to do scale change handling even though the dpi was
unchanged, because the window resized by only a couple of pixels.
Pretty much the same test plan as b4c4c85683
but start wezterm:
./target/debug/wezterm -n --config 'ssh_domains={{name="s",remote_address="localhost"}}' connect s
This reliably propagates focus=true events, but if the client switches
focus away from a mux pane to a local pane, then the focus=false event
may not be propagated to the remote mux.
refs: #1608
We don't assume that we start up focused, and some WM don't tell
us our focus state, so prior to painting, if we don't know the
focus state, explicitly query it and synthesize a focus change event.
refs: https://github.com/wez/wezterm/issues/1757
Flesh out the get_os_parameters impl for macOS. When running on a
system that provides `NSScreen::safeAreaInsets`, use that to determine
the border required to avoid the "notch" on certain models of mac.
In the GUI layer: when the os parameters include a border, adjust
the render position to account for it.
This is a bit of a speculative change, as I don't have a mac with
a notch.
refs: https://github.com/wez/wezterm/issues/1737
This commit allows specifying a scaling factor as part of the font
attribute definition. This scaling factor is fed through to the
rasterizer and the shaper to adjust the actual font size that is
loaded.
The intent is to provide manual control for situations where the
fallback font has a different scale to the primary font and renders
either too small or too large.
The concrete example is
https://github.com/wez/wezterm/issues/1761#issuecomment-1079708207 where
the CJK fallback looks too small.
The scaling factor doesn't influence font metrics so it may also be
desirable to configure line height.
```lua
local wezterm = require 'wezterm'
return {
line_height = 1.2,
font = wezterm.font_with_fallback({
"JetBrains Mono",
{family="Microsoft YaHei", scale=1.5},
}),
}
```
freetype can't handle a wide range of encodings for
font names and can return strings like `?????` when
the family name is only present in the font as a non-unicode encoding,
such as Chinese.
This commit improves our handling of the font name table
and prefers to use results from processing that over the
results returned for eg: font family directly from the
freetype API.
refs: https://github.com/wez/wezterm/issues/1761
The metadata is useful from a troubleshooting/diagnostic perspective.
`.cast` isn't on github's list of allowed file name suffixes, so make
it a simple text file for convenience.
