This pulls in almost all of the original PR in #2235.
I skipped a dead key case that I recall being tricky:
I didn't want to break the non win32-input mode version
of that.
I'd be happy to have that case re-evaluated in a smaller
PR where we can focus on its details.
Co-authored-by: Dominik Kreutzer <kreudom@gmail.com>
If the client program is drip feeding us input at a rate faster than 1
character per mux_output_parser_coalesce_delay_ms (e.g. it is printing
output read from a serial port faster than this), we would previously
wait indefinitely for new input, because we would always poll with a new
timeout [...]delay_ms in the future. In the worst case, this would create
a busy loop that starves the other panes of an opportunity to read from
their ptys, making all of them unresponsive. Address this by making a
note of when the first character was read, and do not wait longer than
[...]delay_ms after this time.
Fixes#3466.
https://github.com/wez/wezterm/discussions/3480#discussioncomment-5567569
mentioned that running `wezterm cli spawn --domain-name SSH:foo`,
closing that tab and running `wezterm cli spawn --domain-name SSH:foo`
again failed.
The error message had no useful context.
This commit adds more context.
macos doesn't have a num lock concept, so there is no num lock state
reported in modifiers. wezterm doesn't emulate that state because it
cannot guarantee to observe all key presses and correctly track it.
It's obvious that Nushell is intended to be skipped by default for close
confirmation. However, on Windows, Nushell instances are named `nu.exe`,
not `nu`, so they don't get skip-closed properly. Add `nu.exe` alongside
`nu`, so Windows behaves as expected.
We need access to the underlying raw/physical key in order
to correctly encode in some modes, so we need the full KeyEvent
struct for that.
Move the encoder up so it sits alongside the win32 input mode
encoder.
This should give us better results for both shifted/unshifted
and the "base layout" (US english) representations of a number
of keys.
Note that this is still not 100% technically correct: the unshifted
keys require knowledge of the keyboard layout that we don't have
at this OS-independent layer.
Right now we're assuming a US layout to unshift punctuation, which
is not right if you're not using that layout. To resolve that,
more work is needed on each OS to be able to extract that information
and then to store it in the KeyEvent.
refs: https://github.com/wez/wezterm/issues/3479
refs: https://github.com/wez/wezterm/issues/2546
