There are a few notable changes as a result:
* A number of `.ssh/config` options are now respected; host matching
and aliasing and identity file are the main things
* The authentication prompt is inline in the window, rather than
popping up a separate authentication window
Refs: https://github.com/wez/wezterm/issues/457
I can't get this to succeed though; I suspect there may be a lingering
bug from libssh2 and/or trailing support for newer openssh features.
refs: https://github.com/wez/wezterm/issues/457
These now operate in terms of logical lines so they deal with
lines that have wrapped outside the viewport better than in
previous releases.
closes: https://github.com/wez/wezterm/issues/408
The wincng based build doesn't recognize newer keys which makes it
impossible to connect to a reasonably up to date Fedora installation.
This commit points to my branch of ssh2-rs that has some changes to
build ssh2 against the vendored openssl that is already part of
the dependency graph for wezterm.
refs: https://github.com/wez/wezterm/issues/507
Rust 1.51 allows addressesing a long-standing TODO which was that we
shouldn't need to build a vendored copy of openssl on most sensible unix
systems.
We do require a vendored copy on macOS and Windows, but due to the way
that Cargo's feature resolver worked, it wasn't possible for this
requirement to be respected.
Rust 1.51 introduces `resolver="2"` which can deal with this feature
resolution!
https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
The upshot of this is that building wezterm on real unix systems that
are not macos will now link against the system libssl, resulting in both
a shorter compile time and less headaches arising from having a slightly
different openssl used by wezterm than the rest of the system.
cc: @jsgf
It is only used by applications that repaint on a resize event,
and us rewrapping makes it harder to have an ideal view afterwards.
This change makes us more consistent with VTE's behavior in this case.
This helps with https://github.com/wez/wezterm/issues/574 but doesn't
completely resolve it.
If shaping can't resolve some glyphs, queue the font locator
fallback resolution to another thread; meanwhile, a last resort
glyph is used.
That thread can trigger an invalidation once the fallback resolve
is complete, the window is invalidated and the last resort glyph
is replaced by the resolve glyph.
refs: https://github.com/wez/wezterm/issues/559
refs: https://github.com/wez/wezterm/issues/508
Keep track of the glyphs we've already advised about (until the
config is reloaded) so that we don't keep spamming the user.
refs: https://github.com/wez/wezterm/issues/559
* Check built-in fonts before asking the system for codepoint coverage
* If one of the earlier stages resolved some fonts, skip the remaining
stages and speculatively shape what we have. This avoids triggering
the system font lookup for fonts that are present in the font_dirs
or that are built-in, such as powerline symbols.
refs: https://github.com/wez/wezterm/issues/559
