Can't navigate help reference using Ctrl-] on a Belgian keyboard
#11831
Comments
|
### Steps to reproduce
1. Start Vim with a Belgian keyboard
2. Navigate to the help file: `:help expand()
3. Move the cursor to TRUE
4. Hit `Ctrl-$` (the equivalent to `Ctrl-]` on a Belgian keyboard)
Vim cursor move to the end of the line where we expect to go to the
definition of TRUE
### Expected behaviour
This was the behavior with Vim 8.2 and is the behavior with Neovim
### Version of Vim
9.0.1164
Is that in the console, Windows Terminal or in the GUI?
### Environment
Operating System: Windows 10
We did have a fix for CTRL-[ before (patch 9.0.0087), but that involved
handling a dead key, so it's different.
How do you type "[" normally? It appears the key produces "$" without a
modifier.
What happens if you press that key with CTRL and the modifier you
normally use to get "["?
You can use CTRL-V or CTRL-K in Insert mode before pressing the key to
see what you get then.
…--
hundred-and-one symptoms of being an internet addict:
28. You have comandeered your teenager's phone line for the net and even his
friends know not to call on his line anymore.
/// 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 ///
|
|
The considered key is CTRL-] (Jump to definition) and not CTRL-[ as in your list of question. In a Belgian keyboard the But in previous version of Vim and in the actual version of Vim you can get the behavior of CTRL-] (jump to definition) by hitting CTRL-$ The previous case was indeed CTRL-[ that we used to reached using CTRL-^ (the ^ being a deadkey in the Belgium keyboard) |
|
Vivian, as far as I remember I also found that and it was possible to work it around with 'nmap <c-$> <c-]>' or something like that? Edit: (my finding was in w32 gvim) |
|
Is this something we can write tests for? for example in test_mswin_event.vim? @ant0sha Is this possibly helped by your open PR about switching keyboard layouts in gVim? |
Using my PR for switching kbd layouts one can test such things, yes. But I fear kbd layout(s) need to be also configured in the OS of the machine, where test is running. Probably therefore it always failed in CI - not sure though. Locally it worked fine. |
|
I confirm that the workaround @ant0sha is working |
|
To answer @brammool: |
According to @vds2212 (chatted outside of tracker) "It works fine in console but not in gVim" |
|
I confirm that the workaround @ant0sha is working
```
nnoremap <C-$> <C-]>
```
I wonder if we can make this change without breaking it for other
environments:
…--- a/src/misc2.c 2023-01-14 21:07:04.002952303 +0000
+++ b/src/misc2.c 2023-01-18 13:57:20.389467164 +0000
@@ -1559,6 +1559,13 @@
return '^';
if (key == '-')
return '_';
+
+ // On a Belgian keyboard AltGr $ is ']', on other keyboards '$' can only be
+ // obtained with Shift. Assume that '$' without shift implies a Belgian
+ // keyboard, where CTRL-$ means CTRL-].
+ if (key == '$' && (modifiers & MOD_MASK_SHIFT) == 0)
+ return ']';
+
return key;
}
--
How To Keep A Healthy Level Of Insanity:
14. Put mosquito netting around your work area. Play a tape of jungle
sounds all day.
/// 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 ///
|
|
@brammool, proposed change of may_adjust_key_for_ctrl() would most probably solve it for w32 gvim and GTK gui. A bit unclear is how it is about plain X11 (motif) - motif front-end handled ctrl_dead_circumflex already as ESC, no idea how - so for that ctrl-$ topic similar surprises are possible. Anyway if nothing interfere, will try those 3 front-ends this weekend. No idea how it can influence w32 console or WT, or classical Unix pty - that's question for others. Anyway a bit disturbing fact is that it works already without your proposed patch in w32 console (and my best guess that it works without patch in classical Unix pty as well, otherwise there would be long ago complains from Belgium?). In classical pty (xterm under Linux) I can try it as well, not pretending to understand code though. Are there more front-ends? |
|
On a Belgian keyboard, Ctrl-] is not Ctrl-$ but Ctrl-AltGr-$ (I have such a keyboard and it took me literally years to find that). If you can't access that key combo, or if it is too complex for you, you can do like I did before I found out how to produce a Ctrl-] on a Belgian keyboard: add to your vimrc map <F9> <C-]>
map! <F9> <C-]>(You may use anything else, preferably an F key, instead of F9). This way, you can (with this example) use F9 not only to jump to a tag (including a help tag) but also (in Insert mode) to trigger an abbreviation. Best regards, |
|
P.S. Now I know how to get Ctrl-] on a "raw" Belgian keyboard, but in Vim or gvim I still use F9 as above. |
|
Here are the result of my tests: Ctrl-* behave like Ctrl-] on:
Ctrl-* doesn't behave like Ctrl-] on:
In my tests:
|
Short summary for the patch:
TLDR description: Here are results: Patch on Motif don't quite work - although I see the "key" value Although not quite working on Motif this seems not to break
Patch do not works for PTY on xterm - code in GTK3 and W32 GUI variants both work fine with patch. Patch is If someone would please do test of this patch with W32 CMD.exe "AZERTY <C-$> acts like QWERTY <C-]>" Patch proposed is a step towards harmonization. |
|
@brammool:
> I wonder if we can make this change without breaking it for other
> environments:
> ```
> --- a/src/misc2.c 2023-01-14 21:07:04.002952303 +0000
> +++ b/src/misc2.c 2023-01-18 13:57:20.389467164 +0000
> @@ -1559,6 +1559,13 @@
> return '^';
> if (key == '-')
> return '_';
> +
> + // On a Belgian keyboard AltGr $ is ']', on other keyboards '$' can only be
> + // obtained with Shift. Assume that '$' without shift implies a Belgian
> + // keyboard, where CTRL-$ means CTRL-].
> + if (key == '$' && (modifiers & MOD_MASK_SHIFT) == 0)
> + return ']';
> +
> return key;
> }
> ```
Short summary for the patch:
- Motif - don't work, needs improvement, although apparently also
not breaks anything
- GKT3 - works fine
- PTY (vim in xterm) - probably noop, concerns, but hopefully not
breaks anything
- W32 GUI - works fine
- W32 CMD.exe - UNTESTED
- W32 WT (windows terminal) - UNTESTED
TLDR description:
Here are results:
```
-------------+------------+------+------+---------+
| |AZERTY|AZERTY|AZERTY |
Front-End | Version |C-^ as|C-$ as|C-AltGr-$|
| |EN C-[|EN C-]|as EN C-]|
-------------+------------+------+------+---------+
Motif | v9.0.1224 | Y | N | Y |
Motif | v9.0.1224p | Y | N | Y |
GTK3 | v9.0.1224 | Y | N | Y |
GTK3 | v9.0.1224p | Y | Y! | Y |
W32 GUI old | v8.2.4005 | Y | Y | N |
W32 GUI new | v9.0.1224 | Y | N | N |
W32 GUI new | v9.0.1224p | Y | Y! | N |
W32 CMD.exe | - | - | - | - |
W32 WT | - | - | - | - |
PTY on xterm | v9.0.1224 | Y | N | Y |
PTY on xterm | v9.0.1224p | Y | N | Y |
-------------+------------+------+------+---------+
```
Patch on Motif don't quite work - although I see the "key" value
returned by may_adjust_key_for_ctrl(...) is altered, but later,
after "key = may_adjust_key_for_ctrl(...)" assignment, "key" is
not used to feed VIM internal keys buffer, but rather (unaltered)
string[] array is used for that: "add_to_input_buf(string, len);"
Thanks for checking! Thus the patch would already fix the problem in a
couple of cases.
For Motif, I guess this additional patch is needed:
--- a/src/gui_x11.c 2023-01-22 21:14:32.617863616 +0000
+++ b/src/gui_x11.c 2023-01-23 12:08:57.147352734 +0000
@@ -936,11 +936,11 @@
}
else
{
- len = mb_char2bytes(key, string);
-
// Some keys need adjustment when the Ctrl modifier is used.
key = may_adjust_key_for_ctrl(modifiers, key);
+ len = mb_char2bytes(key, string);
+
// Remove the SHIFT modifier for keys where it's already included,
// e.g., '(', '!' and '*'.
modifiers = may_remove_shift_modifier(modifiers, key);
This moves encoding "key" into "string" to after
may_adjust_key_for_ctrl() may have changed the value of "key".
Although not quite working on Motif this seems not to break
anything. After "key" is modified, it used in two subsequent
calls. (By the way, that Motif code looks not so nice already
before patch since ``may_adjust_key_for_ctrl`` may change the
value of ``key`` even before patch). 2 subsequent calls are:
- ``may_remove_shift_modifier`` - it should be noop because
code of patch in ``may_adjust_key_for_ctrl`` is only triggered
for the case when SHIFT is hold.
- ``check_for_interrupt`` - seems to be streamlined to catch
Ctrl_C cases only, therefore should not interfere with neither
<kbd><C-$></kbd> nor with <kbd><C-]></kbd>
Patch do not works for PTY on xterm - code in
may_adjust_key_for_ctrl() is not called at all in that case in my
tests. My understanding of check_termcode() function is not
enough yet to tell more for this case, I am interested to look on
it on the long run but it will take time. So here potentially it
may be get called for corner cases, when in PTY some specific key
protocolls are activated?
I wonder how it currently happens for CTRL-2 (works like CTRL-@) and
CTRL-6 (works like CTRL-^). I haven't tracked this down yet.
[...]
…--
I wonder how much deeper the ocean would be without sponges.
/// 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 ///
|
|
On Mon, Jan 23, 2023 at 04:35:09AM -0800, Bram Moolenaar wrote:
> @brammool:
> > I wonder if we can make this change without breaking it for other
> > environments:
> > ```
> > --- a/src/misc2.c 2023-01-14 21:07:04.002952303 +0000
> > +++ b/src/misc2.c 2023-01-18 13:57:20.389467164 +0000
> > @@ -1559,6 +1559,13 @@
> > return '^';
> > if (key == '-')
> > return '_';
> > +
> > + // On a Belgian keyboard AltGr $ is ']', on other keyboards '$' can only be
> > + // obtained with Shift. Assume that '$' without shift implies a Belgian
> > + // keyboard, where CTRL-$ means CTRL-].
> > + if (key == '$' && (modifiers & MOD_MASK_SHIFT) == 0)
> > + return ']';
> > +
> > return key;
> > }
> > ```
>
> Short summary for the patch:
>
> - Motif - don't work, needs improvement, although apparently also
> not breaks anything
> - GKT3 - works fine
> - PTY (vim in xterm) - probably noop, concerns, but hopefully not
> breaks anything
> - W32 GUI - works fine
> - W32 CMD.exe - UNTESTED
> - W32 WT (windows terminal) - UNTESTED
>
> TLDR description:
>
> Here are results:
> ```
> -------------+------------+------+------+---------+
> | |AZERTY|AZERTY|AZERTY |
> Front-End | Version |C-^ as|C-$ as|C-AltGr-$|
> | |EN C-[|EN C-]|as EN C-]|
> -------------+------------+------+------+---------+
> Motif | v9.0.1224 | Y | N | Y |
> Motif | v9.0.1224p | Y | N | Y |
> GTK3 | v9.0.1224 | Y | N | Y |
> GTK3 | v9.0.1224p | Y | Y! | Y |
> W32 GUI old | v8.2.4005 | Y | Y | N |
> W32 GUI new | v9.0.1224 | Y | N | N |
> W32 GUI new | v9.0.1224p | Y | Y! | N |
> W32 CMD.exe | - | - | - | - |
> W32 WT | - | - | - | - |
> PTY on xterm | v9.0.1224 | Y | N | Y |
> PTY on xterm | v9.0.1224p | Y | N | Y |
> -------------+------------+------+------+---------+
> ```
>
> Patch on Motif don't quite work - although I see the "key" value
>
> [snip]
Thanks for checking! Thus the patch would already fix the problem in a
couple of cases.
For Motif, I guess this additional patch is needed:
--- a/src/gui_x11.c 2023-01-22 21:14:32.617863616 +0000
+++ b/src/gui_x11.c 2023-01-23 12:08:57.147352734 +0000
@@ -936,11 +936,11 @@
}
else
{
- len = mb_char2bytes(key, string);
-
// Some keys need adjustment when the Ctrl modifier is used.
key = may_adjust_key_for_ctrl(modifiers, key);
+ len = mb_char2bytes(key, string);
+
// Remove the SHIFT modifier for keys where it's already included,
// e.g., '(', '!' and '*'.
modifiers = may_remove_shift_modifier(modifiers, key);
This moves encoding "key" into "string" to after
may_adjust_key_for_ctrl() may have changed the value of "key".
Looks correct, will give it a try, may be this weekend again.
> [snip]
>
> Patch do not works for PTY on xterm - code in
> may_adjust_key_for_ctrl() is not called at all in that case in my
> tests. My understanding of check_termcode() function is not
> enough yet to tell more for this case, I am interested to look on
> it on the long run but it will take time. So here potentially it
> may be get called for corner cases, when in PTY some specific key
> protocolls are activated?
I wonder how it currently happens for CTRL-2 (works like CTRL-@) and
CTRL-6 (works like CTRL-^). I haven't tracked this down yet.
At least on termux terminal (pretends to be TERM=xterm when it's
not) it is clear. vim get already ^@ if user press ^2 from termux
terminal:
2124.692332 : raw key input: ""
And ^^ if one press ^6:
266.885145 : raw key input: "^^"
(In last case char code of ^^ char in ch_log in vim = output of
'norm ga' command = "<^^> 30, Hex 1e, Oct 036, Digr RS")
"raw key input" traces are apparently coming in this case from
``ch_log()`` call, right after ``len = read(read_cmd_fd, (char
*)inbuf + inbufcount, readlen);`` line inside
``fill_input_buf()``, can be confirmed by following stack trace
for ^6 watch expression in gdb:
```
Thread 1 "vim" hit Hardware watchpoint 17: (typebuf.tb_buf[typebuf.tb_off]!=30)
Old value = 1
New value = 0
0x0000007baef5d610 in __memcpy () from /apex/com.android.runtime/lib64/bionic/libc.so
(gdb) bt
#0 0x0000007baef5d610 in __memcpy ()
from /apex/com.android.runtime/lib64/bionic/libc.so
#1 0x0000005e90f0c560 in _ZL7memmovePvU17pass_object_size0PKvm (dst=0x5e90fc51d6 <typebuf_init+106>,
src=0x5e90fcbf74 <inbuf>, len=1)
at /data/data/com.termux/files/usr/include/bits/fortify/string.h:66
#2 read_from_input_buf (
buf=0x5e90fc51d6 <typebuf_init+106> "\036\066\066\066\033\033\036", maxlen=1) at ui.c:896
#3 inchar_loop (
***@***.***=0x5e90fc51d6 <typebuf_init+106> "\036\066\066\066\033\033\036",
***@***.***=52, ***@***.***=-1,
***@***.***=429,
wait_func=0x5e90e4f298 <WaitForChar>,
resize_func=0x5e90e4f2c4 <resize_func>)
at ui.c:396
#4 0x0000005e90e4f298 in mch_inchar (
***@***.***=0x5e90fc51d6 <typebuf_init+106> "\036\066\066\066\033\033\036", maxlen=-1862484108,
***@***.***=52, wtime=1, ***@***.***=-1,
tb_change_cnt=-1, ***@***.***=429)
at os_unix.c:407
#5 0x0000005e90f0c3c0 in ui_inchar (
***@***.***=0x5e90fc51d6 <typebuf_init+106> "\036\066\066\066\033\033\036", maxlen=52,
***@***.***=-1, tb_change_cnt=429)
at ui.c:232
#6 0x0000005e90dd6920 in inchar (
buf=0x5e90fc51d6 <typebuf_init+106> "\036\066\066\066\033\033\036", maxlen=<optimized out>,
wait_time=-1) at getchar.c:3766
#7 0x0000005e90ddac04 in vgetorpeek (
advance=<optimized out>, ***@***.***=1)
at getchar.c:3547
#8 0x0000005e90dd9790 in vgetc ()
at getchar.c:1739
#9 0x0000005e90ddb828 in safe_vgetc ()
at getchar.c:1990
#10 0x0000005e90d747f0 in edit (
***@***.***=97,
startln=<optimized out>, ***@***.***=0,
count=<optimized out>)
at edit.c:594
```
Another proof is how ``sed`` shows those keycodes with their
octal values as you type them:
```
$ sed -n l
^^
\036$
^@
\000$
^C
```
e.g after starting ``sed -n l``, type "^6, Enter, ^2, Enter, ^c".
But what happens with VIM on real xterm puzzles me to be honest.
Output in of test with ``sed`` is same as fro termux. But in
ch_log it differs.
This comes to vim if one press ^6 in xterm:
```
3.385932 : raw key input: "[27;5;54~"
3.385994 : setting seenModifyOtherKeys to TRUE
3.386028 : SafeState: reset: key typed
3.386077 : ERROR: E23: No alternate file
3.386113 : SafeState: Start triggering
3.386147 : looking for messages on channels
3.386154 : SafeState: back to waiting, triggering SafeStateAgain
```
With ^6 string from ch_log() "[27;5;54~" filtered via xxd:
```
00000000: 221b 5b32 373b 353b 3534 7e22 0a ".[27;5;54~".
```
And this comes to vim for ^2 in xterm:
```
4.516747 : raw key input: "[27;5;50~"
4.516801 : setting seenModifyOtherKeys to TRUE
4.516839 : SafeState: reset: key typed
4.516893 : SafeState: Start triggering
4.516921 : looking for messages on channels
4.516929 : SafeState: back to waiting, triggering SafeStateAgain
```
With ^2 string from ch_log() "[27;5;50~" filtered via xxd:
```
00000000: 221b 5b32 373b 353b 3530 7e22 200a ".[27;5;50~" .
```
With best regards, Anton
|
|
[...]
> I wonder how it currently happens for CTRL-2 (works like CTRL-@) and
> CTRL-6 (works like CTRL-^). I haven't tracked this down yet.
At least on termux terminal (pretends to be TERM=xterm when it's
not) it is clear. vim get already ^@ if user press ^2 from termux
terminal:
> 2124.692332 : raw key input: ""
And ^^ if one press ^6:
> 266.885145 : raw key input: "^^"
(In last case char code of ^^ char in ch_log in vim = output of
'norm ga' command = "<^^> 30, Hex 1e, Oct 036, Digr RS")
OK, so Vim already gets the character with the CTRL modifier applied.
But what happens with VIM on real xterm puzzles me to be honest.
Output in of test with ``sed`` is same as fro termux. But in
ch_log it differs.
This comes to vim if one press ^6 in xterm:
```
3.385932 : raw key input: "[27;5;54~"
3.385994 : setting seenModifyOtherKeys to TRUE
3.386028 : SafeState: reset: key typed
3.386077 : ERROR: E23: No alternate file
3.386113 : SafeState: Start triggering
3.386147 : looking for messages on channels
3.386154 : SafeState: back to waiting, triggering SafeStateAgain
```
With ^6 string from ch_log() "[27;5;54~" filtered via xxd:
This is the modifyOtherKeys encoding of the character 6 (which is ASCII
54 decimal) with the CTRL modifier (5). Vim can decode this, and then
the CTRL modifier still needs to be applied (this appears to work, I
haven't tried to find where in the code this happens).
…--
hundred-and-one symptoms of being an internet addict:
40. You tell the cab driver you live at
http://123.elm.street/house/bluetrim.html
41. You actually try that 123.elm.street address.
/// 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 ///
|
|
On Mon, 23 Jan 2023 04:35:28 -0800, Bram Moolenaar wrote:
For Motif, I guess this additional patch is needed:
--- a/src/gui_x11.c 2023-01-22 21:14:32.617863616 +0000
+++ b/src/gui_x11.c 2023-01-23 12:08:57.147352734 +0000
@@ -936,11 +936,11 @@
}
else
{
- len = mb_char2bytes(key, string);
-
// Some keys need adjustment when the Ctrl modifier is used.
key = may_adjust_key_for_ctrl(modifiers, key);
+ len = mb_char2bytes(key, string);
+
// Remove the SHIFT modifier for keys where it's already included,
// e.g., '(', '!' and '*'.
modifiers = may_remove_shift_modifier(modifiers, key);
This moves encoding "key" into "string" to after
may_adjust_key_for_ctrl() may have changed the value of "key".
Just tested, solved for Motif now.
As additional check, tried to find possible regression:
- on QWERTY-US langmap "imap <C-s-$> ctrl_shift_dollar"
- still producing in insert mode ctrl_shift_dollar - before and
after patch
- in xterm+VIM (with modifyOtherKeys)
- in Motif GUI
On Wed, Jan 25, 2023 at 07:05:06AM -0800, Bram Moolenaar wrote:
[...]
> > I wonder how it currently happens for CTRL-2 (works like CTRL-@) and
> > CTRL-6 (works like CTRL-^). I haven't tracked this down yet.
>
> At least on termux terminal (pretends to be TERM=xterm when it's
> not) it is clear. vim get already ^@ if user press ^2 from termux
> terminal:
>
> > 2124.692332 : raw key input: ""
>
> And ^^ if one press ^6:
>
> > 266.885145 : raw key input: "^^"
>
> (In last case char code of ^^ char in ch_log in vim = output of
> 'norm ga' command = "<^^> 30, Hex 1e, Oct 036, Digr RS")
OK, so Vim already gets the character with the CTRL modifier applied.
Another examples of such terminals:
- "st"-terminal (TERM=st-256color)
- gnu-screen session started from "st"-terminal (TERM=screen-bce)
- gnu-screen session started from xterm (TERM=screen.xterm-256color)
- ... probably there are many others ...
In those cases patch of may_adjust_key_for_ctrl() has no effect,
since may_adjust_key_for_ctrl() is not called in such terminals.
VIM receives following "raw key input" from such terminals:
CTRL+$
11.127991 : raw key input: "$"
> <$> 36, Hex 24, Oct 044, Digr DO
CTRL+6
233.722126 : raw key input: ""
> <^^> 30, Hex 1e, Oct 036, Digr RS
Interesting exception is plane tty (linux console) with activated
be-latin1 keymap ("sudo loadkeys be-latin1"): instead of sending
just "$" like other "dumb terminals" linux console somehow
generates nice "^]" already:
CTRL+$
37.872252 : raw key input: "^]"
> <^]> 29, Hex 1d, Oct 035, Digr GS
CTRL+6
542.722776 : raw key input: "^^"
> <^^> 30, Hex 1e, Oct 036, Digr RS
This mystery reminds me of pre-8.2.4807 W32 gvim, which has
similar behavior, without us undertaken anything for that. My
best guess is, that Win API ``TranslateMessage()`` call has some
such interesting non-obvious "tunings" for key codes mapping,
coded for whatever reasons by some microsoft guys... And we lost
it after stopped to call ``TranslateMessage()`` in this famous
"improve processing of key events" commit 8.2.4807.
> But what happens with VIM on real xterm puzzles me to be honest.
> Output in of test with ``sed`` is same as fro termux. But in
> ch_log it differs.
>
> This comes to vim if one press ^6 in xterm:
>
> ```
> 3.385932 : raw key input: "[27;5;54~"
> 3.385994 : setting seenModifyOtherKeys to TRUE
> 3.386028 : SafeState: reset: key typed
> 3.386077 : ERROR: E23: No alternate file
> 3.386113 : SafeState: Start triggering
> 3.386147 : looking for messages on channels
> 3.386154 : SafeState: back to waiting, triggering SafeStateAgain
> ```
>
> With ^6 string from ch_log() "[27;5;54~" filtered via xxd:
This is the modifyOtherKeys encoding of the character 6 (which is ASCII
54 decimal) with the CTRL modifier (5). Vim can decode this, and then
the CTRL modifier still needs to be applied (this appears to work, I
haven't tried to find where in the code this happens).
For what it worst, following is a backtrace for breakpoint on
may_adjust_key_for_ctrl() if CTRL+6 pressed in xterm:
Thread 1 "vim" hit Breakpoint 1, may_adjust_key_for_ctrl (modifiers=4, key=54) at misc2.c:1546
1546 if (!(modifiers & MOD_MASK_CTRL))
(gdb) bt
#0 may_adjust_key_for_ctrl (modifiers=4, key=54) at misc2.c:1546
#1 0x0000000000685f13 in put_key_modifiers_in_typebuf (key_arg=54, modifiers_arg=4, csi_len=10,
offset=0, buf=0x0, bufsize=0, buflen=0x0) at term.c:5288
#2 0x00000000006860af in handle_key_with_modifier (arg=0x7ffe1c331e14, trail=126, csi_len=10, offset=0,
buf=0x0, bufsize=0, buflen=0x0) at term.c:5351
#3 0x0000000000686815 in handle_csi (tp=0x8465fa <typebuf_init+90> "\033[27;5;54~", len=10,
argp=0x8465fc <typebuf_init+92> "27;5;54~", offset=0, buf=0x0, bufsize=0, buflen=0x0,
key_name=0x7ffe1c331eee "", slen=0x7ffe1c331ef0) at term.c:5662
#4 0x0000000000687a30 in check_termcode (max_offset=3, buf=0x0, bufsize=0, buflen=0x0) at term.c:6236
#5 0x0000000000533ca8 in handle_mapping (keylenp=0x7ffe1c3320e8, timedout=0x7ffe1c3320f0,
mapdepth=0x7ffe1c3320ec) at getchar.c:2769
#6 0x000000000053453f in vgetorpeek (advance=1) at getchar.c:3232
#7 0x00000000005321ae in vgetc () at getchar.c:1739
#8 0x00000000005328d9 in safe_vgetc () at getchar.c:1990
#9 0x000000000059a57f in normal_cmd (oap=0x7ffe1c3322a0, toplevel=1) at normal.c:750
#10 0x000000000076929f in main_loop (cmdwin=0, noexmode=0) at main.c:1535
#11 0x00000000007685c4 in vim_main2 () at main.c:887
#12 0x0000000000767cdb in main (argc=3, argv=0x7ffe1c3324d8) at main.c:433
Have to correct as well original test results for xterm (due to
my mistake first time - done it inside gnu-screen session).
Here it is, together with new terminals checked so far:
-------------+------------+------+------+---------+
| |AZERTY|AZERTY|AZERTY |
Front-End | Version |C-^ as|C-$ as|C-AltGr-$|
| |EN C-[|EN C-]|as EN C-]|
-------------+------------+------+------+---------+
Motif | v9.0.1224 | Y | N | Y |
- Motif | v9.0.1224p | Y | N | Y |
+ Motif | v9.0.1224p | Y | Y! | Y |
GTK3 | v9.0.1224 | Y | N | Y |
GTK3 | v9.0.1224p | Y | Y! | Y |
W32 GUI old | v8.2.4005 | Y | Y | N |
W32 GUI new | v9.0.1224 | Y | N | N |
W32 GUI new | v9.0.1224p | Y | Y! | N |
W32 CMD.exe | - | - | - | - |
W32 WT | - | - | - | - |
PTY on xterm | v9.0.1224 | Y | N | Y |
- PTY on xterm | v9.0.1224p | Y | N | Y |
+ PTY on xterm | v9.0.1224p | ? | Y! | Y |
+ PTY in screen| v9.0.1224p | Y | N | Y 1) |
+ PTY on st | v9.0.1224p | Y | N | Y |
+ PTY on linux | v9.0.1224! | Y | Y | N 2) |
-------------+------------+------+------+---------+
[1] Same results for two cases for vim inside gnu-screen, with
gnu-screen originally started from:
- xterm (TERM=screen.xterm-256color)
- "st"-terminal (TERM=screen-bce)
[2] linux tty console, TERM=linux
With best regards, Anton
|
|
Thanks Anton. Can you tell me what is the status of the patch? Best regards, |
|
I'm not 100% sure this won't break something, but there is no way to find out. |
|
Thanks. |
|
Just for reference, just tried this out on the Mac. It "works", in that Ctrl-$ does indeed trigger Ctrl-] in Vim. That said I looked it up and seems like the macOS keyboard has it such that the way to input "]" is by doing Option-Shift- |
Steps to reproduce
Ctrl-$(the equivalent toCtrl-]on a Belgian keyboard)Vim cursor move to the end of the line where we expect to go to the definition of TRUE
Expected behaviour
This was the behavior with Vim 8.2 and is the behavior with Neovim
Version of Vim
gVim 9.0.1164 (I don't have the problem with the console version of vim)
Environment
Operating System: Windows 10
Logs and stack traces
No response
The text was updated successfully, but these errors were encountered: