1
1
mirror of https://github.com/wez/wezterm.git synced 2024-09-20 11:17:15 +03:00

macos: fix alt+<ascii> key being passed to terminal

This was an unintended casualty of the recent gui layer refactoring.

If you press `option-h` macos generates DOT ABOVE which we pass through
to the terminal key processing layer.  It sees that ALT is set and emits
an escape byte (to indicate that ALT is set) followed by the UTF-8
sequence for DOT ABOVE.  `zsh` gets confused and treats this as
`<ffffffff>` in its line editor.

This diff restricts the emission of the ESC leader to ascii alphanumeric
characters only.

There needs to be a followup diff to allow configuring how we process
these ALT modified characters on macOS because our current behavior
breaks eg: `ALT-1` which is a hotkey that I use in tmux.  Granted that
I don't need tmux with end to end wezterm, but it does prevent me from
using that if I wanted to.
This commit is contained in:
Wez Furlong 2019-11-04 18:46:40 -08:00
parent 44d1b031e2
commit 03f51f7be2

View File

@ -866,7 +866,12 @@ impl TerminalState {
buf.push((c as u8 - 0x60) as char);
buf.as_str()
}
(Char(c), _, ALT, ..) => {
// When alt is pressed, send escape first to indicate to the peer that
// ALT is pressed. We do this only for ascii alnum characters because
// eg: on macOS generates altgr style glyphs and keeps the ALT key
// in the modifier set. This confuses eg: zsh which then just displays
// <fffffffff> as the input, so we want to avoid that.
(Char(c), _, ALT, ..) if c.is_ascii_alphanumeric() => {
buf.push(0x1b as char);
buf.push(c);
buf.as_str()
@ -1020,7 +1025,7 @@ impl TerminalState {
| (InternalPasteEnd, ..) => "",
};
// debug!("sending {:?}", to_send);
// debug!("sending {:?}, {:?}", to_send, key);
writer.write_all(to_send.as_bytes())?;
// Reset the viewport if we sent data to the parser