<C-_> bug still not fixed in v8.2.5157: different behavier between vim and gvim, about <C-_>

[dantezhu]

Steps to reproduce

1. open vim.exe, type Ctrl and -, wait sometimes, it will show like this:
   

2. open gvim.exe, type as before, it will show like this:
   

3. The different behavier will make some bugs, such as tcomment.vim use <c-_><c-_> to comment line, but now it counld not works well.

4. open gvim.exe, type Ctrl + Shift + -, it will show the same value as vim.exe:
   

   but this is not same behavier with vim, and not same with old gvim.

Expected behaviour

type Ctrl and -, gvim should output as vim.

Version of Vim

v8.2.5157

Environment

windows 10 x64
china

Logs and stack traces

No response

[dantezhu]

this commit: patch 8.2.5157 has not fix the bug

[dantezhu]

pls help to check it again, tks.
@LemonBoy

[dantezhu]

@brammool

[ladayaroslav]

But #10579 is, indeed, fixed (WFM, at least).
Thank you, @LemonBoy!

Though now I noticed some strange behavior related to langmap (with any value of langremap).
Using correct langmap for Russian:

set langmap=ёйцукенгшщзхъфывапролджэячсмитьбюЁЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮ;`qwertyuiop[]asdfghjkl\;'zxcvbnm\\,.~QWERTYUIOP{}ASDFGHJKL:\"ZXCVBNM<>

• With :set showcmd, typing "fyy correctly shows the same, but pressing the same keys being switched to Russian layout shows "<0430>yy there.
• While the manual states: "Your language characters will be understood as normal vim English characters (according to the langmap mappings) in the following cases: Normal/Visual mode (commands, buffer/register names, user mappings)", the "user mappings" part doesn't work: using nnoremap sw :echo 'Software?'<CR>, it just performs "s" (:help s) while being switched to Russian layout.

I didn't pay attention to any of this before --- most probably, the behavior is not new.
I hope this information helps with further investigation.

[brammool]

Niva also reports: Ctrl+F or B broken since 8.2 patch 5157 in gui windows
I assume this is in a French setup.

[dantezhu]

@brammool hi，btw, I am using chinese

[dantezhu]

may be it's better to revert the change of patch 8.2.4807 first, then try to find a perfact solution.
I find that lots of issues about Ctrl are created recently.

@brammool @LemonBoy

[brammool]

8.2.4807 has been included quite a while ago. Rolling it back now does not appear to be a good solution.
It appears 8.2.5157 is the one causing most problems now. Then there are a few remaining issues to be fixed.

[LemonBoy]

Try something like the following, it fixes the problems with ctrl keys for me.

-           if (len == 0 && keyboard_state[VK_CONTROL])
+           if (keyboard_state[VK_CONTROL]
+                   && (len == 0
+                       || (len == 1 && (ch[0] < 0x20 || ch[0] == 0x7f))))

Thanks Bram for rolling back this 'fix'. Very surprised by the regression caused, I wonder how this patch can pass the tests. If I can help in the future to add or run tests, please let me know.

Shit's hard to 'fix' properly because there are no tests at all.

[LemonBoy]

And <C-_> should really be <C-S-_> because you're also pressing the shift key, that's intended according to the comments in may_remove_shift_modifier.

[brammool]

And `<C-_>` should really be `<C-S-_>` because you're also pressing the shift key, that's intended according to the comments in `may_remove_shift_modifier`.

Is that true for all keyboard layouts? The keyboards I know have "-" on the key and produce "_" with shift, but there might be keyboards where this is not so. Curly braces are in a different place on different keyboards, with French for example.

…

-- An operatingsystem is just a name you give to the rest of bloating idiosyncratic machine-based-features you left out of your editor. (author unknown) /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[dantezhu]

And <C-_> should really be <C-S-_> because you're also pressing the shift key, that's intended according to the comments in may_remove_shift_modifier.

@LemonBoy Thanks for your explanation. Yes, that might indeed be justified without historical debt. But we should at least keep the behavior of gvim and vim consistent, which is currently inconsistent, so it's a bit strange.
I'm not quite sure how macvim will behave after merging the latest vim kernel code, but at least macvim's <C-_> is consistent with vim for now.

[char101]

<C-2>, <C-6>, <C--> are special cases as can be seen in the console code. The GUI key handling doesn't seem to handle these special cases. Which is why the behaviour is different.

[dantezhu]

@char101 I see, thank you. If it is consistent, it feels that the cost of understanding is lower. After all, many people use both gui and console.

[char101]

The handling of these keys is indeed removed in 8.2.4807.

Looking at Japanese keyboard layout, it indeed doesn't have @ in 2, ^ in 6, nor _ in -, which is why <C-2>, <C-6>, and <C--> are mapped to <C-@>, <C-^>, and <C-_>.

[dantezhu]

The handling of these keys is indeed removed in 8.2.4807.

Looking at japanese keyboard layout, it indeed doesn't have @ in 2 and ^ in 6, which is why <C-2> and <C-6> are mapped to <C-@> and <C-^>.

Actually I wish they were added back, 😀

[zoumi]

<A-x> maps have problem too.

noremap <A-s> :w!<CR>

Left Alt-s will trigger this, but Right Alt-s can't.

[dantezhu]

@LemonBoy @brammool
Hi, Sorry to bother you, may I know if this issue will be scheduled to be fixed? Thank you.

[risa2000]

@dantezhu @char101 @zoumi
You guys might want to check #12595 where I am giving my observations on the whole affair. (I came late to the party as I only recently tried to update my Vim).

[chrisbra]

We will need to find a way how to move forward with this. Given the recent loss of Bram, not sure we will have time for this soon unfortunately.

[ladayaroslav]

We will need to find a way how to move forward with this. Given the recent loss of Bram, not sure we will have time for this soon unfortunately.

I understand. Unfortunately, it's still severely broken.

IMHO, what's probably being incorrectly presumed here is that everyone uses the latest vim patch on Windows. Which might be far from truth, i.e. most users might still have not installed a recent vim version (perhaps, even 8.2.4807 that broke it first time!), so the volume of complaints could increase if/when it happens.

[risa2000]

@chrisbra Following your surprising post I just learned about Bram! I also read your post on Google groups that you have an access to the project and are willing to take over, which would make you the person to address my proposal related to the patch 77fc0b0 and the following fallout:

Could we do a "soft" rollback of the patch, i.e. putting back the old handling, making it default, and define some internal variable which will allow enabling the patch behavior as an experimental feature?

This way it should preserve the same behavior for everyone who used Vim before patch without problems, and still allow people who want (and can actually) use the new behavior to work on it. I guess there is a quite lot of work to be done to make it right. And once the behaviors of the branches are the same, we may flip the switch. But it should be done after and not before the behavior is correct.

For that I would expect to have some kind of keyboard/keypress generator/simulator, built in, which would be able to check the layouts behavior in both paths and report the regressions.