-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GVim operator pending with remapped keys getting cancelled #5302
Comments
Related to #5300 (comment) . Thanks for the quick fix! I tested the new version, and there still seems to be an issue left when keys are remapped.
**Steps to reproduce**
1. Run `gvim --clean`
2.
```
:set timeoutlen=9999<cr>
:onoremap qq i[<cr>
i[hello]<esc>h
dq
*alt-tab*
q
```
If you do the alt-tab, the final q press does nothing. If you don't do
the alt-tab, doing "dqq" deletes the text between the brackets as it
should. The alt-tab somehow messes gVim up - it changes Vim's state
instead of getting totally ignored. The same happens if you use
xbindkeys to remap keys - if you have a mapping ctrl+x -> q and try to
do "d<ctrl-x><ctrl-x>", typing ctrl+x cancels operator pending, and
when the virtual q press is received, Vim prompts for a macro instead
of deleting the text inside the brackets.
I tried looking at the source code and I assume the problem is that
you'd need to bail earlier when a control keycode is received, but the
character is read inside the normal_cmd with safe_vgetc and that might
be too late if the state change happens in the main_loop. Or maybe
some control character isn't being recognized right?
I tried compiling an earlier version of Vim that I knew had worked and
it had the same problem now - seems one of the dependencies has
changed and caused the new issue.
Unfortunately this is hard to fix. The focus events are passed into the
typeahead buffer, thus get in between the two "q" keys.
Fortunately it's very unusual to type half a mapping and then change
focus. In your example there is unlikely a reason not to type "qq" at
once.
I'll add this to the todo list, but I don't expect it can be fixed soon.
…--
If Microsoft would build a car...
... the oil, water temperature, and alternator warning lights would
all be replaced by a single "General Protection Fault" warning light.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Thank you! This is indeed not a problem most people are likely going to have, and it's only caused me problems with keyboard remaps (have ctrl+{7,8,9,0} bound to paren characters). I'll try looking some more into the code too, see if I can help fix it. Maybe the typeahead buffer can be set to ignore irrelevant control characters in GUI |
Thank you! This is indeed not a problem most people are likely going
to have, and it's only caused me problems with keyboard remaps (have
ctrl+{7,8,9,0} bound to paren characters).
I'll try looking some more into the code too, see if I can help fix
it. Maybe the typeahead buffer can be set to ignore irrelevant control
characters in GUI
It's complicated. The K_IGNORE gets in the way, or the
focuslost/focusgained events which get turned into K_IGNORE in vgetc().
Sometimes they can indeed be ignored, in this case after another
character was typed that may start a mapping. However, in other cases
it must return from vgetc() so that we make a pass through the loop to
handle side effects.
…--
The CIA drives around in cars with the "Intel inside" logo.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to #5300 (comment) . Thanks for the quick fix! I tested the new version, and there still seems to be an issue left when keys are remapped.
Steps to reproduce
gvim --clean
If you do the alt-tab, the final q press does nothing. If you don't do the alt-tab, doing "dqq" deletes the text between the brackets as it should. The alt-tab somehow messes gVim up - it changes Vim's state instead of getting totally ignored. The same happens if you use xbindkeys to remap keys - if you have a mapping ctrl+x -> q and try to do
d<ctrl-x><ctrl-x>
, typing ctrl+x cancels operator pending, and when the virtual q press is received, Vim prompts for a macro instead of deleting the text inside the brackets.I tried looking at the source code and I assume the problem is that you'd need to bail earlier when a control keycode is received, but the character is read inside the normal_cmd with safe_vgetc and that might be too late if the state change happens in the main_loop. Or maybe some control character isn't being recognized right?
I tried compiling an earlier version of Vim that I knew had worked and it had the same problem now - seems one of the dependencies has changed and caused the new issue. It seems to behave the same way on Ubuntu's pre-packaged versions with other GUIs too - vim-athena and vim-gtk3.
Sorry for the trouble!
Environment
The text was updated successfully, but these errors were encountered: