Further constrain the hiding logic for key-down events, so that
we are less likely to hide for things ctrl-shift-c when the user
is mousing around and copy/pasting.
Also, consider CapsLock to be a modifier for this and other
similar purposes.
refs: #3570
refs: #3306
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>
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
We were missing encoding of these for the base xterm encoding
(I haven't daily driven a keyboard with a numpad in over 10 years!).
Improve mapping for the kitty protocol.
refs: https://github.com/wez/wezterm/issues/3478
This commit teaches the termwiz layer about positional modifiers,
and expands our modifier concept to also pass through led states
such as caps lock and num lock.
Those aren't actually keyboard modifiers, but the state is useful
to recognize.
Adjust the shift key normalization so that we don't uppercase
alpha characters when both SHIFT and CAPS_LOCK are held.
This processing will remove both SHIFT and CAPS_LOCK in that
situation.
Add a method to KeyEvent that will undo the OS keyboard layer
normalization of positional to generic modifier key presses.
eg: the OS may map LeftControl -> Control, but we actually
prefer to have LeftControl so if we can unambiguously reverse
that mapping, we do so.
refs: #3476
refs: #3475
added a new `ui_key_cap_rendering` option that accepts the following
values:
```lua
-- Super, Meta, Ctrl, Shift
config.ui_key_cap_rendering = 'UnixLong'
-- Super, M, C, S
config.ui_key_cap_rendering = 'Emacs'
-- Apple macOS style symbols
config.ui_key_cap_rendering = 'AppleSymbols'
-- Win, Alt, Ctrl, Shift
config.ui_key_cap_rendering = 'WindowsLong'
-- Like WindowsLong, but using a logo for the Win key
config.ui_key_cap_rendering = 'WindowsSymbols'
```
refs: https://github.com/wez/wezterm/issues/3335
For items in the main set of key assignments, show the keyboard
shortcut to the right.
Some items have multiple key assignments; we show only the first
one. We'll probably want to be a bit smarter. For instance,
both linux and windows tend to occupy the Windows/Super key
assignments, so we should probably prioritize showing the Ctrl+Shift
variants on those platforms.
refs: https://github.com/wez/wezterm/issues/3335
We need to manually convert to string, as the default ToDynamic
impl encodes the underlying bits value from the bitfield and
that doesn't round trip with the try_from String impl
When using the win32 keyboard encoding, the delete and backspace keys
were encoded with the wrong character codes compared to the native
terminal. This caused subtle issues in multiple applications.
This change brings the encoding in line with the native terminal.
I think this might only be a thing on Windows.
This commit speculatively (I'm on a mac at the moment!) allows tracking
the left/right control/shift modifier flags and passing that through
to the win32 input mode logic.
refs: https://github.com/wez/wezterm/issues/2009
Avoid using serde for mapping between Lua and Rust for the `Config`
struct.
This improves the build speed of the config crate by 2x; it goes down
from 30 seconds to 9 seconds on my 5950x.
We want to avoid normalizing control key presses; there were
two places where it was happening; one in our own code and
the other was in the xkeyboard mapping stuff itself.
refs: https://github.com/wez/wezterm/issues/1851
I'm not sure that we strictly want/need this normalization function
any more, but I'm hesitant to blanket remove it without having time
to really investigate further.
cc: @CIAvash
When considering "F" we'd try to parse it as "F<NUMBER>" and fail,
so fall back to producing `Physical(F)` instead.
Since this was in the context of CMD-F in the default keymap code,
we'd then generate ctrl-F as an equivalent when considering the
ctrl-shift case.
cc: @CIAvash
The recent switch to DeferredKeyCode introduced a bit of ambiguity
when parsing certain keys.
One issue was with the map that was used for some parsing didn't have
consistent/distinct entries for physical vs. mapped.
Another issue is that the key resolution for the simple case where
a key had the same physical and mapped representations would always
return the mapped one even when physical mode was set as a preference.
This commit kills the ambiguous map in favor of an string conversion
method on KeyCode.
It's possible that this will help with https://github.com/wez/wezterm/issues/1826
a little, but I started looking at this because there were a couple of
comments about Alt-Enter and some numpad keys no longer working in the
Element channel.
A bit of a PITA, this commit:
* Introduces a DeferredKeyCode type that defers resolving a concrete
keycode
* Adds key_map_preference config which can be Mapped or Physical
* Key map building resolves the keycode using key_map_preference
* Default key assignments have been re-phrased in order to produce
DeferredKeyCodes
* User-specified keys without `mapped:` or `phys:` prefixes will
resolve according to key_map_preference
refs: https://github.com/wez/wezterm/issues/1788
refs: https://github.com/wez/wezterm/issues/1784
