Fix MacVim Ctrl-C handling in Normal and Command-Line modes #856
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Vim has a "ctrl_c_interrupts" mode that gets turned on in misc modes (e.g. Normal / Command-Line mode) when <C-C> is not mapped. In this mode, Ctrl-C has special behavior and is hard-coded (i.e. not remappable). There is an old bug in how MacVim handles Ctrl-C under this mode. It's trying to be smart and aggressively clears the input queue (even non-text-related ones) without adding anything to the input queue. Previously it kind of worked due to a coincidence in how Vim's GUI handled input logic, but it was fragile. The recent Vim refactor that changed Vim GUI's input handling broke this. Instead, don't do any of these smart input queue clearing and just do what Vim GUI code in other platforms does and call `trash_input_buf()`, set `set_int`, and then add the Ctrl-C to the input queue. MacVim still has `Cmd-.` for an aggressive interrupt in case Vim is hung (which shouldn't happen to begin with). Fix macvim-dev#846
ychin
force-pushed
the
ctrl-c-interrupt-fix
branch
from
c313b6f
to
066dd1f
Compare
ychin
added a commit
to ychin/macvim
that referenced
this pull request
Feb 18, 2019
Vim patch 8.1.950 Fixes: - Fix Ctrl-C not working properly in Command-Line and Normal mode macvim-dev#856 - Fix scrollbar rendering artifact in macOS 10.13 or below macvim-dev#857 - matchit plugin now works again in MacVim (fixed in Vim 8.1.0875) Targets macOS 10.8+ Script interfaces have compatibility with these versions: - Lua 5.3 - Perl 5.18 - Python2 2.7 - Python3 3.7 - Ruby 2.6
ychin
added a commit
that referenced
this pull request
Feb 18, 2019
Vim patch 8.1.950 Fixes: - Fix Ctrl-C not working properly in Command-Line and Normal mode #856 - Fix scrollbar rendering artifact in macOS 10.13 or below #857 - matchit plugin now works again in MacVim (fixed in Vim 8.1.0875) Targets macOS 10.8+ Script interfaces have compatibility with these versions: - Lua 5.3 - Perl 5.18 - Python2 2.7 - Python3 3.7 - Ruby 2.6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Vim has a
ctrl_c_interruptsmode that gets turned on in misc modes (e.g. Normal / Command-Line mode) when<C-C>is not mapped. In this mode, Ctrl-C has special behavior and is hard-coded (i.e. not remappable).There is an old bug in how MacVim handles Ctrl-C under this mode. It's trying to be smart and aggressively clears the input queue (even non-text-related ones) without adding anything to the input queue. Previously it kind of worked due to a coincidence in how Vim's GUI handled input logic, but it was fragile. The recent Vim refactor that changed Vim GUI's input handling broke this.
Instead, don't do any of these smart input queue clearing and just do what Vim GUI code in other platforms does and call
trash_input_buf(), setset_int, and then add the Ctrl-C to the input queue. MacVim still hasCmd-.for an aggressive interrupt in case Vim is hung (which shouldn't happen to begin with).Fix #846