The error message in this issue sounds a lot like the freetype
regression that caused bitmap fonts to fail to render in a recent
freetype release.
Our workaround for that is to used our understanding of whether
a font is a bitmap font or not to avoid calling render.
What we normally see for bitmap TTFs is that setting the scale
fails and we then fall back to using a bitmap.
For Monaco.dfont it appears as though setting the scale succeeds.
This commit introduces some skepticism and prefers to use bitmaps
when available.
This might potentially cause problems in the future if there are
fonts that legitimately have both scaled and bitmap fonts, but
lets see if this helps for now.
refs: https://github.com/wez/wezterm/issues/1419
Finally getting around to fixing this usability wart: this commit
changes the behavior of Window closing so that you can close a window
containing multiplexer panes without prompting and without killing
off those panes.
This is achieved through some plumbing:
* The mux can now advise Domains about an impending window closure,
giving them the opportunity to "do things" in readiness.
* The mux client domain informs the container ClientPane instances
to ignore the next Pane::kill call, which would otherwise inform
the mux server to kill the remote pane
* Pane:can_close_without_prompting now requires a CloseReason.
* ClientPane's can_close_without_prompting impl allows Window closing
without prompting on the assumption that the ignore-next-kill hack
above is working
refs: #848
refs: #917
refs: #1224
The mux client just returns a dummy reader, and some overlays
have panicking stubs: just allow for them to return None
instead of potentially spawning a useless thread.
This commit adds plumbing to support mapping the process tree to
lua objects which in turn allows a new `mux-is-process-stateful`
event to be defined by the user for finer control over closing
prompt behavior.
refs: #1412
Previously, we would only look at the `check_for_updates` config
on startup.
This commit adjusts the update checker logic so that we always
start it, and that we respect config reloads.
Only show the update window and/or generate a toast notification
is the current wezterm-gui process is the eldest of the set of
running wezterm-guis.
This avoids spamming the user with update information.
refs: https://github.com/wez/wezterm/issues/1402
It looks like the debian 9 test failures with libssh are the
same underlying issue as https://github.com/wez/wezterm/issues/1262
Poking around in the debug output, and then spelunking through the code,
we can use the `pubkeyacceptedtypes` ssh config option to add the key
type to the list of keys. This doesn't appear to be a documented
option in the current versions of openssh.
I'm not 100% sure that this is right, but it's worth a shot.
```
thread 'e2e::sftp::canonicalize_should_either_return_resolved_path_or_error_if_missing' panicked at 'Unexpected result from canonicalize: Err(LibSsh(Sftp(SftpError(2))))', wezterm-ssh/tests/e2e/sftp.rs:615:14
```
We can't currently match that error because the LibSsh SftError(x) error
code is private.
Route logging via the `log` crate because on Windows there is
no stderr visible to libssh.
libssh will override any explicitly set options when it parses
the config file, so we need to apply those after we've loaded it.
A recent cargo update caused openssl-sys to do a minor semver update
from 0.9.71 -> 0.9.72, but that release downgraded from openssl 3
to openssl 1 to resolve a performance regression:
<https://github.com/sfackler/rust-openssl/pull/1578>
That in turn caused libssh to fail to build because the ENGINE
feature required by libssh isn't compiled in in openssl-src 1
crate when vendoring on windows.
For now, my libssh git repo is constrained to openssl-sys 0.9.71,
and we're pointing to that from the wezterm repo.
For some reason, winapi's HANDLE type isn't compatible with the core
rust ffi HANDLE type when cross compiling.
This commit adds some casts.
```
cd pty
cargo build --release --target x86_64-pc-windows-msvc
```
refs: #1389
The texture coordinates into the source image weren't quite right;
previously we'd do this math:
num_cells = (image_size / cell_size).ceil()
delta = num_cells / image_size
that would result in the image being stretched to fit across the rounded
up number of cells, leading to a distored image.
This commit changes the delta calculation to be based on the remaining
number of pixels in a given dimension relative to the cell size.
refs: #1300
refs: #1270
This code was partially replicating the initial window setup
where we didn't necessarily know the dpi, but in the context
where this is run, we do know the dpi for the window, so
let's consistently use that number throughout.
refs: #1039
In the mux layer, we have some code that takes a `Child` and then
does a bit of naughty reaching through the abstraction to get at
the pid/handle of the child so that we can send it signals even
if the child is itself mutably (and thus exclusively) borrowed
for the purposes of waiting.
That worked fine for local processes spawned in the mux, but we also
use LocalPane to wrap around arbitrary `Child`ren, such as Ssh,
that are not local and that don't have a local process id, which
meant that this hack wouldn't work for them.
To make things a bit worse, those ssh ptys were used to ssh2 days
where we didn't have a way to signal the remote process and just
did nothing, leading to confusing situations such as
https://github.com/wez/wezterm/issues/1197
This commit graduates the hack mentioned in the first paragraph
to its own ChildKiller trait. This makes the concept of waiting
for the Child distinct from signalling it and explicitly allows
getting a separate object that can be used for signalling.
With that in place, we're forced to implement something appropriate
for the ssh pty implementations; one in the pty crate itself,
one in wezterm-ssh and the wrapper that we use in the mux crate.
The upshot of this is that the `CloseCurrentPane` action now operates
correctly on panes that were the result of split operations.
