Ctrl+Arrow on the command line doesn't work under Win Terminal

[mixmastamyk]

Hi, am a heavy user of skipping words on the command line via the Ctrl+left and Ctrl+right hotkeys.

Bash/fish and cmd.exe and GUI textareas support it, although they differ slightly on the right arrow. The Unix shells go to the end of the word (rather than beginning of next) when moving to the right. Probably to be able to edit the end of the word more quickly. I don't have a strong preference here.

Hopefully Yori could support it as well.

[malxau]

Ctrl+left and Ctrl+right are implemented. They differ a little from CMD, in that CMD navigates to the next word whereas Yori navigates to the next program argument, which seemed more logical to me. So if the input string is This is text, the two should behave identically. If the input string is "Text grouped" into "different arguments", then Yori would see three parts where CMD would see five.

What behavior are you seeing?

[mixmastamyk]

Very interesting! It seems that is only Windows Terminal that has the problem. Regular console works. Not sure why since WT handles the same keystrokes for cmd and bash. Weird!

Maybe the keystrokes are whitelisted per interpreter, because it doesn't respond to them, as if I didn't press them. But then try the next keystroke like Ctrl+E or A and it works fine.

Do you happen to do anything "non-standard" in the implementation? If not I'll file a bug at WT .

[malxau]

Interesting. I'm traveling right now and don't have access to WT to have a closer look. As far as non-standard, note the three shells are interacting with the console in three different ways:

• CMD asks the console for a line of text. The console is responsible for implementing Ctrl+arrow. I don't know quite how this is architected with ConPTY + WT.
• bash talks to the console using VT sequences. It will read from input a stream of text which it then interprets to be an arrow. This may be done via helper libraries outside of the core bash code.
• Yori talks to the console using low level Win32 input. In the new WT world, ConPTY has to translate the VT sequences into their Win32 equivalent. The "obvious" way this would go wrong is to not have the same mask of control characters, although I'm assuming that left and right (without Ctrl) both work, and these are handled in the same way, so there's something about holding down Ctrl that is indicating more than just Ctrl to the yori process.

[mixmastamyk]

I could file a bug on this one at WT if it helps.

[malxau]

Did you end up filing a WT bug? I'm back from traveling and looking at this under a debugger the problem is indeed that the mask of control characters is different. Win32 (for whatever reason) has a flag ENHANCED_KEY which denotes a key added in the 101 key AT keyboard. I was never sure why this existed in this form, because by 1993 when NT was released, I don't think it would have supported any device with a pre-AT keyboard. But anyway, the normal arrow keys should generally have this flag set, since they're AT keys and WT is not setting that flag.

The reason non-Ctrl arrows work is because I added a fallback for this case when somebody pointed out that the arrows in the number pad of their 101 key keyboard don't work, because those are the original XT, non-enhanced arrows. So I think I should continue adding these fallbacks in other code paths so that number pad arrows work the same as regular arrows, but I still think WT's Win32 translation isn't accurate in this case. Those are two different keys, and they should have two different low level key codes.

(What's more funny with WT is something like "history -u", where because of this behavior the arrows don't work, and mouse doesn't work because WT doesn't have that yet, so the UI is completely useless.)

[mixmastamyk]

I haven't filed it, because I hadn't heard confirmation from you. Sounds like you'd like to have two bugs, one for each project?

[malxau]

It looks like Terminal already have a bug for this, it's microsoft/terminal#2397 .

I just pushed a fix to support number pad arrows more consistently, so with this fix Ctrl+arrow should also work under WT whether the translation is fixed there or not.

[mixmastamyk]

Thanks. ;-)

[malxau]

I just released 1.21 which I believe fixes this issue. You can upgrade an existing install with ypm -u. If you find any additional problems, please either reopen this issue or file a new one describing that problem. Thanks for the report!

[mixmastamyk]

Thanks, you're doing the lord's work, haha. Making Windows tolerable for those not interested in power shell.