Pause/delay before ctrl-k (editor:cut-to-end-of-line) takes effect


#1

For the last few releases (maybe since 0.140 or so?) ctrl-k has started behaving differently: when pressed, nothing happens immediately, but then about 1 second later, the cut actually takes effect.

However, if the cursor is moved immediately after the ctrl-k, the cut takes effect immediately. (i.e. the cut happens after ~1 second has elapsed or the cursor is moved, whichever happens first.)

Is there some way to fix this?


Ctrl-k (editor:cut-to-end-of-line) deleting *next* line
#2

This is likely because there’s partial keybindings that start with ctrl-k. Press cmd-. (ctrl-. on win32/linux) to open the keybinding resolver and then press ctrl-k. It should show “ctrl-k (partial)” and some keybindings, then it will change to show the editor:cut-to-end-of-line binding.

On my Atom, the minimap package adds ctrl-k ctrl-m and ctrl-k ctrl-s which causes this pause.

It waits because it needs to make sure you’re not about to press the second half of a key combination. You can fix it by removing/unsetting the partial keybindings that begin with ctrl-k.

The delay is set to 1000ms and was last changed in March: https://github.com/atom/atom-keymap/commit/22164708e88a7a0c8709cec3495c71cb44a17dc6


#3

Aha, you’re totally right, and minimap was the problem for me too, thank-you!

For reference, to remove the minimap keybindings (I don’t need keyboard shortcuts to toggle on/off), I needed to add the following to my keymap.cson:

'.workspace':
  'ctrl-k ctrl-m': 'unset!'
  'ctrl-k ctrl-s': 'unset!'

#4

I think it’ll be time that I get rid of these commands, or at least of their binding, on that note it’ll be interesting to get some feedback on how many user deactivate the autoToggle feature, my guess is that nearly no one does.


#5

I leave autoToggle on always.