I had rather a lot of text on my clipboard whenever I accidentally right clicked inside Putty (with Vim open), and Vim has initiated a paste operation which has been going for around ten minutes now.
I don't want to lose my unsaved work, is there a way to instruct Vim to stop pasting text?
If you're in normal mode, Ctrl-C aborts the current command in progress. Then press u to undo anything that changed before you stopped it.
Depending os your vim configuration, there's chances that you have a swap file (backup) in .nameOfTheOpenedFile.swp (substitute nameOfTheOpenedFile with the name for your file).
To recover the file :
vim -r .nameOfTheOpenedFile.swp
I know this is really old but the top answer is not right and I was clearly having a similar issue to OP. (accidentally pasted like a million lines of json into vim)
Keep in mind this may not allow you to save your work (but you can probably salvage something from the .swp file)
All you need to do is open a new terminal window and enter pkill vim into the command line.
Related
When I try to paste hundreds of lines or more into Vim, even in paste mode, it takes much longer (10 times or more?) than to paste that same text into TextEdit and save it as a file. I would speculate that Vim is trying to insert one character at a time and that this is slowing things down. When it's quite a large paste, I end up having to save the text with TextEdit and then open it up in Vim. Is there a faster way to paste text in?
If your Vim is compiled with clipboard support (:echo has('clipboard') returns 1) you can simply use "+p or "*p.
If it's not (:echo has('clipboard') returns 0), get yourself a proper Vim. On Mac OS X, MacVim is the way to go.
I would speculate that Vim is trying to insert one character at a time and that this is slowing things down.
This is correct. Given how terminal works, it can't go any other way. Use GVim/MacVim in GUI mode, and the problem should go away.
Alternately, you can use terminal commands to speed things up. For example, on a Mac, you can do
:r!pbpaste
to paste whatever is in your clipboard below the current line. Vim is getting its input from the pbpaste command, not the terminal, so it avoids the terminal's one-character-at-a-time thing. If you're on Linux, see What's like OSX's pbcopy for Linux.
Another avenue of approach is to see where the hundreds of lines are coming from. If it's from another file, load it into a Vim buffer, then use Vim's native copy-paste (y, p). If it's an output from a command, consider redirecting the command's output to a file first. If it's a webpage, curl it. Clipboard and copy-paste don't really figure into the original terminal-based workflow; pipes and files do.
Simple. First copy the content and then:
pbpaste > /path/to/newfile
Problem:
If the file "tmp.rb" has been modified, the command "e tmp.rb" will fail.
I'm seeking for a command to succeed in both following conditions:
If "tmp.rb" is not in the buffer list, the file will be loaded;
If "tmp.rb" is already in the buffer list and been modified, the
buffer will be loaded(in current window).
Clarification:
Sorry for all the misleadings. Indeed a single command e tmp.rb will achive both as long as the modified "tmp.rb" is not loaded into the current window, in which situation I prefer e tmp.rb does not cause an error and has the same effect as b tmp.rb. Maybe this little concern will make scripting around buffers, windows etc. a little more easily.
The :edit command fails when the buffer is already loaded and modified to prevent you from accidentally overwriting the changes. If you do want to override, use :edit! instead. In many Vim commands, an appended bang (!) forces the command. Alternatively, if you want Vim to ask you for confirmation, use :confirm edit.
I couldn't reproduce your problem.
What I do to try reproduce your problem is
Open tmp.rb with vim, write some thing and save.
In other shell,
$ echo > tmp.rb
Enter :e or e: tmp.rb in vim and it reopen the file without any problem.
If other program is accessing the tmp.rb at the same time this other program maybe are locking the file and because of it you are having the trouble you describe.
The title of your question says "OR" but its body says "AND".
Vim's commands are usually very precise, it's rare to see an ambiguous command that does multiple mutually exclusive things. The number of keys you can use to enter insert mode (iaIAsScCoO) is a perfect example of this.
You should use the appropriate command for each situation:
:e tmp.rb
:b tmp.rb
If you don't mind installing plugins, CtrlP's :CtrlPMixed may help you with its nice abstraction.
I have vimx installed, so I can copy in vimx to the x clipboard by using "+y and the like, which works well as long as I can keep the current vimx running.
However, I also love to be able to switch to the current running shell with ctrl-z and be able to paste what I copied from vim into the shell. Does anyone know how to do this, because as soon as I suspend vim with ctr-z the x-clipboard becomes empty, until I put vim into the fg again.
ok,
After about an hour of head bashing this issue, I have decided to use a different approach to do the same thing.
I will detail what I did here for the benefit of those with the same issue.
If you have wxcopy on your system that is enough to get copy/paste support on your system between vim and other apps. If you want to copy from vim, select the text using v or V or whatever method you prefer, then use the command :tee >(wxcopy). This will copy that code into the oldschool X11 cut buffer. This buffer has the added bonus of not requiring the parent application to be running for pasting to work, hence my problem goes away.
I realize it may be hard to get your hands on wxcopy, under fedora the package that provides it is:
WindowMaker
This isn't an answer as much as a push in the right direction, but start here:
:help quoteplus
:help x11-cut-buffer
Specifically the second help text has some interesting notes about suspending vim. It claims to write the buffer into PRIMARY and CUT_BUFFER0 so you can still use middle click after you've suspended. Maybe you've deleted those or a plugin is interfering? Maybe you are running an old version of vim (I'm running 7.2.182).
My suggestion is to disable all plugins you've manually installed and try vanilla vim. If that doesn't work, consider using vim's -V (verbose) flag and see if it will try to put the buffer into PRIMARY or CUT_BUFFER0 before it actually gets suspended.
I don't have vim compiled with X (vimx) so I can't actually test this myself. Hopefully that gets you in the right direction.
If I'm editing a file in Vim, then some external program changes the file, Vim tells me:
W11: Warning: File "test.erl" has changed since editing started
See ":help W11" for more info.
[O]K, (L)oad File:
If I Load the file, though, all the undo history is lost.
Is there any way to avoid that?
Update: it appears that this is one of the new features in Vim 7.3: https://groups.google.com/group/vim_announce/browse_thread/thread/66c02efd1523554b
I don't believe this is possible.
There is a very useful patch available for the vim source code available here that keeps the undo history after exiting vim and restarting. However, I've just tried it and it seems to fail when the file is edited externally. It might be worth contacting the author or reporting a bug on the patch website to see if this can be overcome.
G'day,
I'm not sure but does setting autoread, i.e. entering :set autoread leave the undo history for the file when it changes?
Hmmmm. I'm thinking probably not because the change history is maintained as line numbers and vim doesn't know if those line numbers are still relevant to the changed file.
BTW WTF are you editing a file that is being changed by external forces anyway? Sounds dangerous to me. (-:
This is a workaround I used before Vim 7.3:
" :e usually clears undo history, so we don't really do :e any more.
" Instead we delete the contents of the buffer, then read the file in, which
" is an operation we can undo. We must delete the top (empty) line also.
:map :e<Enter> :%d<Enter>:r<Enter>:0<Enter>dd
When you see the warning prompt, you would have to hit ok instead of load, and then perform the load yourself: :e<Enter>
There are two disadvantages (although I found the tradeoff acceptable):
You lose the line you were on. Your cursor is left sitting at the top of the file.
Vim still thinks the buffer is out of sync with the file, so when you next save, you may need to do :w! instead of the normal :w, and you will need to hit y to confirm the overwrite.
Edit: There might be a workaround for the second problem.
Edit: The first problem could be addressed with a bit more scripting (see :h line.)
I don't see how vim could keep track of something it didn't do.
So, as to the question, I would suggest - source control ... but that's probably not the answer you're looking for.
My Macbook was stuck yesterday, when I tried to paste 1200 lines of 80 characters to Vim. It was much faster to download the file, and not to paste the text.
I have thought that this problem might be the reason, why internet operators allow slower uploading than downloading.
If you paste it into a terminal window, Vim thinks you're typing it out by hand, and it will try and update the display as you go. You can access your clipboard (on OS X) using the pbpaste and pbcopy commands, so you can just do this in Vim:
:read !pbpaste
or in a shell:
bash$ pbpaste | vim -
If you were using GUI Vim, you would use the "* register to paste (this is what the context menu does):
"*P <- in normal mode
Pasting into the terminal window is usually a bad idea, try and use pbpaste where you can.
:read !pbpaste
If you are using Linux use:
xsel --clipboard --output
or:
xclip -selection clipboard -o
instead of pbpaste.
That is "normal". It's slow because redrawing the text thousands of times is slow.
As you paste the long line in, it's constantly update the display (because of how vim deals with text, or how the terminal is handing vim text, I guess).
I tried pasting the text in vim (using iTerm) and it has the same issue, it takes a while to paste. I tried :set paste and :set nowrap and still as slow. Pasting the line straight into a terminal is equally slow
With the dpaste link you mention, there is a plain-text link, which you could just wget and edit:
curl http://dpaste.com/115362/plain/ | vim -
I favor set paste/nopaste like Masi suggested.
In .vimrc, you can map some character to toggle paste (if often needed).
i.e.
set pastetoggle=ยง
did you try paste mode? set paste / set nopaste?
if you :syntax off you can sometimes improve an in place paste of a long single line file. An example would be a machine generated xml file.
you can probably disable vim's redraw whilst pasting as well, look at :he redraw , but it's always worth using command line stuff as If you are repeating the procedure or similar you can always automate it with a script / vim macro
I don't know if this is a Mac issue or something else, but I have no problems whatsoever with pasting that amount of text in Vim. I have tried on Windows and Linux, and haven't seen any problems.
I have successfully edited files of several hundred megs (log files) in Vim (loading is slow, but once the text is read everything is pretty snappy).
But if it's on the web, you should have tried:
:e http://link/to/file
Then if necessary save it as a local file.
And if it's slow because of the redrawing, look at this option:
*'lazyredraw'* *'lz'* *'nolazyredraw'* *'nolz'*
'lazyredraw' 'lz' boolean (default off)
global
{not in Vi}
When this option is set, the screen will not be redrawn while
executing macros, registers and other commands that have not been
typed. Also, updating the window title is postponed. To force an
update use |:redraw|.
And if it's a local file, then pasting is not necessary: try
:read file
instead.
If you use Apple Terminal try an other terminal, like iTerm.
Sometimes, the "build-in" terminal is not really reactive for common task. Don't know why...