The warning is that some of the variants are never read.
In the case of ftwrap, they are referenced via ffi.
For the other locations, we want them for debug purposes.
The original thinking was to build all in release mode so that
there was less overall redundancy between building out the released
binaries and what we need to build for test purposes. The goal was to
minimize compile time.
I don't believe that that holds up any more, especially with the
prior commit explicitly breaking out the separate binary builds
to manage dependency bloat.
In particular, strip-ansi-escapes' dep graph is expanded
by the overall set of enabled crate features when doing an
indiscriminate `cargo build` vs. `cargo build -p strip-ansi-escapes`.
This may help to avoid tripping over whatever is problematic
in https://github.com/wez/wezterm/issues/5074
Wait until set_inner_size() has finished before repainting. If we
repaint while our request to resize is in progress, our understanding of
the current size of the window may be inconsistent with the actual size,
causing the rendered contents of the window to bounce around.
When using an exec domain as a default_mux_server_domain, you currently
witness the following behavior:
- Newly started mux-servers create a pane in the exec domain.
- Splitting an existing pane will create the new pane in the exec
domain.
- Calling [wezterm cli spawn] will create a new tab or window in the
exec domain.
- Creating a new tab from the Gui does *not* run in the exec domain.
This appears to be due to the fact that ClientDomain hardcodes an
assumption that the default domain_id of the remote mux-server is 0.
Instead of having ClientDomain issue a SpawnV2 RPC explicitly asking for
domain_id 0, simply use DefaultDomain.
dependabot is trying to update pulldown-cmark, but it won't
work because the API has changed.
The update window is not enabled by default and I don't think
anyone uses it anyway, so let's just remove it and have less
code to compile and maintain.
closes: https://github.com/wez/wezterm/pull/4964
On Windows, to set a window's size, in addition to the size of the
client area, the width and height of the window's "frame" must be
included in the dimensions passed to SetWindowPos() which burdens us in
needing to know the exact size of the window frame so that we can
properly account for its dimensions. Previously, we used
AdjustWindowRect() to account for the frame's dimensions, but the size
of a window's frame can change depending on the DPI of the monitor on
which it is placed, and it appears that neither AdjustWindowRect() nor
AdjustWindowRectEx() account for this automatically. Instead, we use
AdjustWindowRectExForDpi(), passing in the window's DPI, so that we
properly calculate the window's size.
