Crash with 0xC000001D (Illegal Instruction) upon an attempt to send a keystroke using a non-ASCII keyboard layout

[im-tem]

Issue encountered on Windows x86_64 1.0.0 release, steps to reproduce:

1. Set the keyboard layout to be not en-us (e.g. ru-ru)
2. Open edit
3. Attempt to send a keystroke e.g. Alt+F

Debugging the issue seems to point to

edit/src/vt.rs

Line 175 in e8d40f6

return Some(Token::Text(&input[beg..self.off]));

as the place in the edit's code which leads to the issue.

[lhecker]

Had a chance to debug this just now. Thankfully it's super easy to test in debug builds. The issue is here:

edit/src/vt.rs

Lines 179 to 180 in e8d40f6

	let c = bytes[self.off];
	self.off += 1;

and here:

edit/src/vt.rs

Lines 208 to 209 in e8d40f6

	let c = bytes[self.off];
	self.off += 1;

Those two need to detect and reject bytes >= 0x80, because they're non-ASCII, and handle them as if they didn't exist (= abort the sequence at that point).

However, this doesn't fix support for non-US keyboards... I'm not entirely sure why, but Alt+F results in ESC а (where "а" is https://codepoints.net/U+0430) as opposed to the expected ESC f.

[kant2002]

Cyrillic a located on the same place as Latin f. So that's indication that we have character and not keycode in the sequence. Not sure where this characters come from exactly. If you give me a bit of hints. I may try to play with it a bit.

[lhecker]

It could be related to this, I think? microsoft/terminal#17197

[lhecker]

I have fixed the crash but there's still the issue that Alt+Unicode results in ESC <Unicode> instead of the expected ESC <ASCII>. I believe this is a bug in both Windows Terminal and conhost, although I could be wrong about that. I filed this issue: microsoft/terminal#18944