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

dantezhu

unread,

Jun 24, 2022, 9:46:11 PM6/24/22

to vim/vim, Subscribed

Steps to reproduce

open vim.exe, type Ctrl and -, wait sometimes, it will show like this:
open gvim.exe, type as before, it will show like this:
The different behavier will make some bugs, such as tcomment.vim use <c-_><c-_> to comment line, but now it counld not works well.

Expected behaviour

gvim should output as vim.

Version of Vim

v8.2.5157

Environment

windows 10 x64

Logs and stack traces

No response

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 24, 2022, 9:47:41 PM6/24/22

to vim/vim, Subscribed

this commit: [patch 8.2.5157] has not fix the bug(4e0fc89)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 24, 2022, 9:48:47 PM6/24/22

to vim/vim, Subscribed

pls help to check it again, tks.
@LemonBoy

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 24, 2022, 9:56:02 PM6/24/22

to vim/vim, Subscribed

@brammool

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

ladayaroslav

unread,

Jun 25, 2022, 1:09:04 AM6/25/22

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jun 25, 2022, 5:10:28 AM6/25/22

to vim/vim, Subscribed

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

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 25, 2022, 5:12:54 AM6/25/22

to vim/vim, Subscribed

@brammool hi，btw, I am using chinese

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 25, 2022, 6:54:07 AM6/25/22

to vim/vim, Subscribed

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

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jun 25, 2022, 8:46:08 AM6/25/22

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

N V

unread,

Jun 25, 2022, 8:56:05 AM6/25/22

to vim_dev

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. NiVa

LemonBoy

unread,

Jun 25, 2022, 9:12:27 AM6/25/22

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

LemonBoy

unread,

Jun 25, 2022, 9:13:55 AM6/25/22

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jun 25, 2022, 9:14:02 AM6/25/22

to vim...@googlegroups.com, N V

> 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. NiVa

There are no tests for this low-level functionality. Perhaps there is a
way to add some, but the main problem is that the behavior of the
libraries with all the different environments is hardly predictable.
Is there a way to simulate actual key presses? And know the expected
result with various keyboard layouts and other settings?

It also appears that problems are reported (long) after a change was
made. Before patch 8.2.4807 was included I asked if it looked OK. But
several problems were reported later.

I have no knowledge of "best practices" of this MS-Windows code. And it
seems various people only understand parts of it. I have no idea if
rolling back 8.2.4807 gives us a better starting point or it's better to
fixe any problems introduced by it.

--
Never enter the boss's office unless it's absolutely necessary. Every boss
saves one corner of the desk for useless assignments that are doled out like
Halloween candy to each visitor.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Bram Moolenaar

unread,

Jun 25, 2022, 9:47:15 AM6/25/22

to vim/vim, Subscribed

> 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 ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 25, 2022, 9:51:40 AM6/25/22

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Charles

unread,

Jun 25, 2022, 10:40:28 AM6/25/22

to vim/vim, Subscribed

<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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 25, 2022, 10:46:56 AM6/25/22

to vim/vim, Subscribed

@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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Charles

unread,

Jun 25, 2022, 10:49:15 AM6/25/22

to vim/vim, Subscribed

The handling of these keys is indeed removed in 8.2.4807.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 25, 2022, 10:58:34 AM6/25/22

to vim/vim, Subscribed

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, 😀

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

zoumi

unread,

Jun 25, 2022, 9:42:42 PM6/25/22

to vim/vim, Subscribed

maps have problem too.

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

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

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

dantezhu

unread,

Jun 30, 2022, 9:47:05 AM6/30/22

to vim/vim, Subscribed

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

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

risa2000

unread,

Aug 6, 2023, 6:40:25 AM8/6/23

to vim/vim, Subscribed

@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).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Aug 6, 2023, 12:21:29 PM8/6/23

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

ladayaroslav

unread,

Aug 6, 2023, 2:01:29 PM8/6/23

to vim/vim, Subscribed

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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

risa2000

unread,

Aug 6, 2023, 2:05:19 PM8/6/23

to vim/vim, Subscribed

@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.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Jan 23, 2024, 5:25:56 PM1/23/24

to vim/vim, Subscribed

Closed #10615 as completed via 68d9472.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward

[vim/vim] <C-_> bug still not fixed in v8.2.5157: different behavier between vim and gvim, about <C-_> (Issue #10615)

dantezhu

Steps to reproduce

Expected behaviour

Version of Vim

Environment

Logs and stack traces

dantezhu

dantezhu

dantezhu

ladayaroslav

Bram Moolenaar

dantezhu

dantezhu

Bram Moolenaar

N V

LemonBoy

LemonBoy

Bram Moolenaar

Bram Moolenaar

dantezhu

Charles

dantezhu

Charles

dantezhu

zoumi

dantezhu

risa2000

Christian Brabandt

ladayaroslav

risa2000

Christian Brabandt