Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Ctrl-C when in command-line mode doesn't work anymore #846

Closed
ychin opened this issue Feb 5, 2019 · 4 comments
Closed

Ctrl-C when in command-line mode doesn't work anymore #846

ychin opened this issue Feb 5, 2019 · 4 comments
Milestone
snapshot-155

Comments

@ychin
Copy link
Member

ychin commented Feb 5, 2019

Seems like snapshot 154 broke this functionality. Pressing Ctrl-C in command-line mode doesn't break out of it anymore, but a follow-on key press would.
@ychin ychin added this to the snapshot-155 milestone Feb 5, 2019
@ychin
Copy link
Member Author

ychin commented Feb 5, 2019 •
edited

Seems like e40b9d4 (v8.1.0834) broke this. It could either be a bug in Vim or a merge error on MacVim's side.

@segeljakt
Copy link

Also, remapping cnoremap <C-c> <Esc> does not work. :/

@mathsaey
Copy link

I'm facing the same issue. Pressing ctrl-c in any mode causes a spike in CPU usage and a noticeable delay. The issue only seems to occur in when using the MacVim gui. (so it doesn't seem to be an issue on the vim side).

@ychin
Copy link
Member Author

ychin commented Feb 13, 2019 •
edited

I'm still looking into this, but the CPU usage bit is interesting info. Just for context MacVim relies on the GUI codebase in Vim itself and basically works as a special type of gVim. That's why when Vim's GUI code goes through refactor like this, sometimes bugs creep in despite a clean merge since we have to re-do some of the changes downstream to match the upstream changes.

ychin added a commit to ychin/macvim that referenced this issue Feb 18, 2019
@ychin
Fix MacVim Ctrl-C handling in Normal and Command-Line modes
c313b6f 
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 other Vim GUI code 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 ychin mentioned this issue Feb 18, 2019
Merged
ychin added a commit to ychin/macvim that referenced this issue Feb 18, 2019
@ychin
Fix MacVim Ctrl-C handling in Normal and Command-Line modes
066dd1f 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
snapshot-155
Development

No branches or pull requests
3 participants
@ychin @mathsaey @segeljakt