Eight bit input mode (like Xterm)

[ggadget6]

Description of the new feature/enhancement

An "eight bit input mode," like XTerm has.

From what I can tell, windows terminal sends alt keys through using escape sequences, but that's not what programs like vim in WSL expect. They expect the 8th bit to be set, like in xterm. This makes using mappings in vim that contain alt not work correctly.

I've been looking at PRs like #6309 because they seem related, but I can't quite tell if this feature already exists, as some of the jargon goes over my head.

[DHowett]

So, this is the first credible request we've had for eight-bit input mode since we started shipping expanded VT input mode years back. Would you mind sharing an example of some things that don't work in vim when Alt is sent as Meta?

I think that supporting 8-bit input mode long-term is going to completely destroy our ability to support the input of any characters whose codepoints are greater than 0x7f. The world has come a very long way since there were only 127 characters, and reserving an entire additional plane for alted input is going to be a hard sell.

[ggadget6]

Hmm, I spent some more time looking into it and it seems like vim is the outlier here. With the current behavior, it is not possible to map Alt+(anything) to anything in vim. You have to use workarounds like mapping (anything) instead, which can be annoying because it adds a delay after using the escape key, so the delay length has to be modified, which could cause further errors (though I'm not sure). If it means you'd have to sabotage future character input, though, I guess it's probably not worth it to implement.

[DHowett]

Alright, I did a quick investigation of a few of our competitors.

It looks like gnome-terminal (vte) and konsole don't offer 8-bit meta mode any longer.

Given that it'll be really difficult to support and keep our core tenet of supporting more than just ASCII, and that the number of applications that are going to require it will trend towards zero with the inexorable march of time, I'm going to close this one out as, regrettably, Won't Fix

It also seems like it might be impossible for us to support. Windows applications generally receive UTF-16 or "native codepage" encoded input. Many of them, however, immediately convert that input to UTF-8. We can't encode an unjacketed character >= 0x80 (high bit set) in UTF-8 and expect it to come across as a high bit set in a 7-bit ASCII glyph through all of the cross-process communication channels that Windows requires.

Since WSL is just a Windows application, at the end of the day, it has to follow suit. We already have an issue where we can't send mouse coordinates using the legacy system >= 93 because they would require a high bit!

[nickjj]

I know this issue is closed but I just wanted to mention that I too would really like to be able to use the alt key for binds in Vim while using the Microsoft Terminal.

Everything @ggadget6 mentioned is how I feel too. The workaround makes the Vim experience quite a bit worse with the timeout delay and escape keys.

Is there any type of workaround to address this without limiting future use? Switching to another terminal is a bit drastic but not being able to bind alt is a big loss. it's a really useful key for performing actions in multiple Vim modes. There's no reasonable substitute in a lot of cases.

[saurik]

@ggadget6 Are you maybe trying to map using A- instead of M-?

[determin1st]

8-bit mode is useful in *nix terminals because keys are sent via text / ESC sequences, 8-bit parser is able to differentiate ESC keypress from ALT+key combo, which is not possible for 7-bit parser.

windows conhost api is completely different story because the ReadConsoleInput supplies keycodes, it doesnt really need 8-bit mode to improve keyboard support

anyway, 8-bit parser is much nicer to implement, 's like aristocracy thing compared to 7-bit entry

here's i wrote how those ALT combo's encoded:
kovidgoyal/kitty#7274