Ctrl underscore sends RET in Emacs and terminal

[sivaramn]

Windows Terminal version (or Windows build number)

Windows Terminal Version: 1.9.1942.0

Other Software

Bug is seen in Emacs 27.2 too in WSL

 wsl --list -v
 NAME            STATE           VERSION
 * Ubuntu-20.04    Running         2

Steps to reproduce

ctrl underscore got by pressing ctrl and _ (underscore)key sends RET in terminal as well as emacs in WSL. ubuntu 20.04

 $uname -a
 Linux CompName 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64     GNU/Linux

$ showkey -a

Press any keys - Ctrl-D will terminate this program

_        95 0137 0x5f
^M       13 0015 0x0d
^D        4 0004 0x04

Expected Behavior

In Emacs Ctrl + _ is usually mapped to undo. It seems to be mapped to RET in emacs as well as terminal as reported above

Actual Behavior

getting RET passed to terminal and in emacs instead of _ or undo in emacs

[DHowett]

What keyboard layout are you using? This is what I am seeing with US-104:

[sivaramn]

does this help? And I don't remember changing my keyboard settings for quite some time; this seems to be recent. Unless, the windows update cycle has changed it, the keyboard layout that is.

[elsaco]

@sivaramn it depends how the keys are pressed. For Emacs undo to work first press crtl then shift+underscore. This will execute undo function in emacs inside WSL instance.

Here's a sample screenshot, notice Undo! in the echo area:

And this is the output of showkey:

_        95 0137 0x5f
^_       31 0037 0x1f

First line is ctrl followed by shift+underscore. The 2nd line is crtl+shift+underscore.

[sivaramn]

@sivaramn it depends how the keys are pressed. For Emacs undo to work first press crtl then shift+underscore. This will execute undo function in emacs inside WSL instance.
First line is ctrl followed by shift+underscore. The 2nd line is crtl+shift+underscore.

Yes, I'm aware of this. I've been using emacs for quite some time and know to C-S _ . C-h k calls RET from simple.el for the key chord which was weird. This seems to be in WSL terminal only as other terminals dont have this issue.

[sivaramn]

problem seems to go away if I switch to

user1@CompName:~$ showkey -a

Press any keys - Ctrl-D will terminate this program

^_       31 0037 0x1f
^D        4 0004 0x04

Still, wouldn't it be a bug that it works differently when the keyboard is switched?

[elsaco]

@sivaramn Emacs has "C+x u" for undo actions. Why not use this key combination instead of "C+S+_" which I find more difficult to type than "C+x u".

[sivaramn]

@sivaramn Emacs has "C+x u" for undo actions. Why not use this key combination instead of "C+S+_" which I find more difficult to type than "C+x u".

True. But I work with both Win and Linux OSes, ctrl-X does cut in Win apps; Ctrl _ works universally without any side effects and unintended results.

[zadjii-msft]

Still, wouldn't it be a bug that it works differently when the keyboard is switched?

Yep, that's a real bug alright. There's a little bit of weird handling for a couple ctrl+key combos, ^_ is one of them. I'll toss this on the backlog, thanks for following up!

[Mathiasdm]

In case it helps: I get this as well in nano and in the terminal, keyboard is 'Belgian (Period)'.

[hvesalai]

I get this for Ctrl+Shift+Minus (i.e. CTRL+_)

$ showkey -a

Press any keys - Ctrl-D will terminate this program

^M       13 0015 0x0d

I would also like to see a very quick fix to this issue as I use Ctrl+_ as my Undo in emacs.

I installed my windows from scratch today and don't remember seeing this before, so something changed when I installed everything again.

[j4james]

For those of you that are getting a ^M when your press Ctrl+Shift+Minus, this is because your keyboard driver doesn't have a mapping for that key combination, so the terminal is forced to generate an appropriate mapping itself. The way it does that is by taking the base key (in this case -, which is ASCII 0x2D), and masking off the lower 5 bits. The result of that mask is 0x0D, which is ^M.

The reason it works correctly on a US keyboard (and several others) is because the keyboard itself has a built in mapping for that key combination, so it doesn't rely on the terminal to do the translation.

I've recently been experimenting with a rewrite of the VT keyboard handler which fixes this bug (amongst other things). However, I don't want to promise that it's going to be fixed soon - it's still very much a work in progress.

[hvesalai]

@j4james do you mean that the US keyboard has a mapping for Shift+Minus or specifically for Ctrl+Shift+Minus.

Indeed I'm on a Finnish keyboard, which is quite different from the US one. On my keyboard Shift+Minus is mapped to produce the underscore, i.e. _, which is 0x5F.

[j4james]

@hvesalai I mean it has a mapping specifically for Ctrl+Shift+Minus. You can see what the mappings are on the Keyboard Layout Info website. Compare the US keyboard layout and the Finnish layout.

On both of them, the minus key is VK_OEM_MINUS (although the position of the key is different). And the US layout has the SHIFT+CONTROL state for that key mapped to ␟ (i.e. 0x1F), while the Finnish keyboard has the CONTROL state alone mapped to ␟. Many keyboard layouts won't have a mapping for that character at all.

What that means is that on your keyboard, Ctrl+Minus should produce the 0x1F character, but don't get too use to that behavior. With my new keyboard implementation that'll stop working, and you'll need to use Ctrl+Shift+Minus, the same as you would on a US keyboard.

[hvesalai]

@j4james OK, that makes a lot of sense. Indeed when using the Terminal, CTRL+Minus works as an Undo in emacs (after I remove the mapping from Terminal's zoom/scaling).