From 03f51f7be23bbcb21ca41d6e9c1cad144b015a52 Mon Sep 17 00:00:00 2001 From: Wez Furlong Date: Mon, 4 Nov 2019 18:46:40 -0800 Subject: [PATCH] macos: fix alt+ 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 `` 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. --- term/src/terminalstate.rs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/term/src/terminalstate.rs b/term/src/terminalstate.rs index cc4d6ee8c..bbac5ea57 100644 --- a/term/src/terminalstate.rs +++ b/term/src/terminalstate.rs @@ -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 + // 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