7

Sometimes I paste a lot of data into vim (>5000 rows) and forget to enable paste mode. In that case, vim is busy for several minutes, trying to correctly indent all the text (which gets REALLY bad performancewise with some kind of data, indenting it by some 10'000 chars).

Is there a way to abort the pasting process? ESC, CTRL-C and CTRL-D don't work.

8
  • I don't know of a way to abort it, but depending on the specific type of vim you have, you can paste from the system clipboard, which doesn't cause Vim to reformat it. Use the + register, e.g. "+P. (Or, in X11, use the * register to paste whatever was last selected; the same text you would get if you middle-clicked into most X apps.) Aug 10, 2012 at 15:26
  • Hm, *P doesn't seem to paste the right things... Neither highlighted text nor ctrl+c content are pasted (it pastes some other data which I don't know where it's coming from). Aug 10, 2012 at 15:37
  • Did you put a double quote before *P? Aug 10, 2012 at 19:07
  • I tried it both with and without double quote, same result... Aug 10, 2012 at 19:31
  • I thought CTRL+C should have worked. I'm curious, what system and version of Vim are you using? And GUI or terminal? Maybe it's a bug...
    – Ben
    Sep 9, 2013 at 5:08

2 Answers 2

5

If you are using the GUI version, you really should paste from either the clipboard register ("*) or the X11 selection ("+), as already suggested by echristopherson. So instead of middle-clicking or whatever, you navigate where you want to paste and then type "*P, including the initial quote. When pasting via the p or P commands, vim knows that you are pasting, hence the 'paste option is unnecessary—no matter from which register you are pasting.

If you are pasting from the terminal, vim doesn't really have a say in the matter. The terminal emulator will dump whatever you have instructed it and in most cases vim cannot differentiate whether the characters that keep coming in are you typing or you pasting. Hence you need to set 'paste to tell vim that it shouldn't do indenting and stuff.

As a consequence, if you are pasting from the terminal, all the characters that are to be pasted are queued in one go and are essentially already sent to vim, so there is really nothing that you can do to interrupt it. From the point of view of the terminal emulator, CTRL+c is but an ordinary character, therefore it gets queued behind all the other stuff that is waiting to be pasted. When vim finally gets to see the CTRL+c, it is too late, as there is nothing to be aborted anymore.

( Update: Depending on the terminal emulator, CTRL+c and similar signals may be sent in a prioritised way. Specifically, I've noticed this in Putty, which delivers the break signal instantly and indeed allows me to abort misplaced lengthy paste operations. I don't really know how this works, though. )


Long story short: If at all possible, use "*P or "+P to paste (which even works in some terminal emulators if I recall correctly). This is the "correct" way to paste; everything else is basically a workaround gives you those kinds of headaches.

0

I just accidentally pasted from tmux instead of pasting from vim's buffer, and tmux happened to have thousands of log lines I'd copied for something else. Without being in paste mode vim was chugging along at maybe 2 lines per second, which would've taken hours.

ctrl+c had no effect as expected. I took a chance and used kill to send SIGINT to the vim process. This actually worked! A bunch of text flew by on the bottom bar too quickly to read, and then I had control again, with just a couple hundred lines pasted.

I've been able to repro this consistently, but I can't find the behavior documented anywhere.

The vim source code reveals what's happening. It looks like the handler will set a got_int variable, which a comment says will "break any loops." Looking for further references to got_int, I found a section that reads the character stream, will pause between reads to check if got_int has been set, and break if it has: https://github.com/vim/vim/blob/master/src/os_unix.c#L5217

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.