Very often (as in multiple times an hour), when I save my file :w, vim tells me "E13: File exists (add ! to override)"
I don't know why it does this, I can't reliably reproduce it, it feels random.
This is my vimrc, note that it sets nobackup, nowritebackup, and noswapfile, and there is a function to strip trailing whitespace that gets run when I save a file.
Also, I tend to have 20 vims open at once, all backgrounded, often editing the same file. Also not improbable that I have the same buffer open in multiple windows (ie :vsp) and might open it, then reopen it with the e command a lot, possibly from a relative filepath, or possibly from an absolute one (the cmap %/ <C-R>=expand("%:p:h")."/"<CR>). No idea if any of this matters. Next time I have this issue, I'll check my ls and report anything odd.
Update:
When I tried to save "lib/seeing_is_believing/wrap_expressions.rb" (note that this is a different file than the one in the gif), this happened again. Here is the ss, it's buffer 3:
Update2 (for #mMontu)
I just realized that there are two errors happening here. The one in the screenshot is the readonly thing. The one in the gif is the more common one, E13: File exists (add ! to override)
The one I just hit is E13 File exists, for this one, readonly is not set:
Update 3
I'm pretty sure the problem is the ZoomWin plugin. I had switched it up to a newer version, and it simply didn't work right. So I stopped using it for a bit, and didn't have this issue. Then switched it back, b/c I miss its functionality (it's my favourite vim plugin), and the problems started again. Possibly it's ZoomWin in conjunction with NerdTree window. Probably not the lib authors' faults, vim in general seems fragile and buggy. Maybe I'll try NeoVim, see if they've done a better job. Maybe it's time to try Atom or Emacs again.
It seems that if there were read errors opening the file, Vim will print an error on :w. This can be seen by running :f:
"MANIFEST.in" [Read errors] 1 line --100%--
The errors aren't necessarily errors in reading the contents of file; they can be caused by a plugin.
I think the main problem is that the file has been modified externally, see http://vim.wikia.com/wiki/Have_Vim_check_automatically_if_the_file_has_changed_externally to reload it whenever this happens
Related
Hi I am trying to update one of my remote repositories. When I use commit in git bash it shows that a SWP file already exists and askes me if I want to (R)ead only the file (E)dit (D)elete. I tried editing the file, but I cannot save the changes and therefore cannot commit my changes. Any idea what is going on.
EDIT:
It's working now thanks to those that helped. In terms of the question I will try to only show the relevant information when asking questions in the future.
When you edit a file, Vim stores your changes in a "swap file" so that you can recover your work if Vim's process is killed before you could save. This can be caused by something as problematic as a system crash or, simply, by closing your terminal window while Vim is running.
If Vim is quitted "normally", it deletes the swap file it created.
If it is not, the swap file is left behind and, the next time you open the same file, Vim will notice the presence of the swap file and offer you the possibility to recover the work that you "lost" the last time Vim quitted "abnormally".
That is the interactive screen you get with the "(R)ead only the file (E)dit (D)elete" prompt.
Now, when you are starting out with stuff like Git, Vim, the command line, etc. it may happen quite often that you find yourself in an uncomfortable situation, not knowing exactly what to do to fix it. This is frankly quite normal at this stage. In those situations, closing the terminal window might seem like a good first step in going back to a more comfortable situation to start again. In some cases, however, doing so might leave a trail of hidden files and broken states that might make it harder than you hoped to get to that comfortable situation.
When you do $ git commit, Git populates a specific temporary file located in your local .git directory:
.git/COMMIT_EDITMSG
with some text describing the commit you are about to make, and opens that file with your designated editor, which is the dreaded Vim by default.
When you start editing the file, Vim creates a swap file. If you insert your commit message, write the file, and quit Vim normally, the swap file is deleted and you won't ever be prompted about it. If you close the terminal window before writing the file, the swap file stays behind and Vim will prompt you about it the next time you try to make a commit.
From there you have quite a few options…
Go into your .git directory and delete the swap file(s) manually. They should be named .git/.COMMIT_EDITMSG.swp (or .swo, .swn, etc. see :help swap-files in Vim). This should give you a clean state for the next time you do $ git commit.
Don't close your terminal window when faced with a problem. Instead, try to analyze what went wrong and look for proper ways to fix it. If you have to close the terminal window, look for stray swap files just in case.
Learn Vim's basics so that you don't have to close the terminal window when you mess up your commits. Try $ vimtutor.
Tell Git to use a text editor you are more familiar with. Search Stack Overflow, I am sure there are dozens of Q/As about that.
Configure Vim to never create swap files. You can do it in Vim's configuration file:
# in $HOME/.vimrc
set noswapfile
This won't tell it to ignore existing swap files, though, so you might want to delete them manually anyway.
Use a graphical Git client instead of the CLI.
EDIT: it turns out if I write to a temporary .go file in the same directory I can then start writing the file again, so I'm almost certain this is a vim-syntastic issue. Going to mark this as closed.
I have an infrequent (but extremely annoying) bug where vim gets confused about where a file is supposed to be written to. It will suddenly decide that it should be writing to "-stdin-", even though :echo expand('%:p') is showing the correct file.
When this happens, there's basically no way to write the buffer back to the correct file. :w % doesn't help, nor does :w NameOfFile.go. I can write to a different filename just fine. :bd does not fix the issue. This only happens if there's a location list open.
Given the lack of google hits for this, I'm guessing this is some kind of issue with my local config. How can I go about debugging this problem?
Edit to add: after posting this, I realized that this is very possibly related to vim-syntastic. I've opened an issue there, but it's definitely possible there's something else causing this.
Marking as closed since this appears to be a vim-syntastic issue.
This is my issue with Vim: you have it open for a couple of days. You're ready to close vim. You don't necessarily want to save all files... you want to skip any files which don't have modified changes, and you want to be left (or be asked) what you want to do with the remaining buffers with unmodified changes…
For anyone that has used Photoshop, this is very familiar… you use it for a week, and when you close Photoshop, it is really trying to close the application, and skips all files which haven't been touched, let's you chose what you want to do with the remaining files, and then closes itself.
It seems like every time I close Vim, I have to go through this circus of doing :qa, then running into a file, doing :bd!, then doing :qa again, run into a file I want, :w, and it's just a huge pain. There has to be a better way of doing this.
If it isn't already obvious… I have :set hidden in my .vimrc.
How about
:confirm qa
It asks you for each modified file whether to save or abandon it (or all remaining). This is the same behavior that GVIM exhibits when you close it via the X in the window title.
does :xa! solve your problem ?
:xa[ll]! Write all changed buffers, even the ones that are readonly,
and exit Vim. If there are buffers without a file name or
which cannot be written for another reason, Vim will not quit.
I was able to find the plugin BufOnly, and then with the help of someone else on StackOverflow, I got an answer that satisfies me:
https://stackoverflow.com/a/14690570/240287
Is it possible to automatically remove the swapfile when the file is saved, and automatically create it again when the file is changed?
And is this a good idea?
EDIT:
The reason for wanting to to this is so that I don't have to go through the diff process for files that had no changes after last save if the computer suddenly ran out of power or crashed.
The diff process referred to is; first open the file read only, saving it under a different filename, vimdiffing it and in the end delete it.
It doesn't happen often, but is just as annoying when it does.
Is it possible to automatically remove the swapfile when the file is saved, and automatically create it again when the file is changed?
And is this a good idea?
Deletion and creation of a file are relatively slow operations. It makes sense to keep the swap file in case if one going to keep editing. Or why else one would keep the VIM running?
Additionally VIM uses the swap file to detect attempts to edit the same file from different VIM instances.
All in all, I think it is a bad idea to try to remove the file.
P.S. Worth noting that when VIM is started in read-only mode as view or vim -R, it doesn't create the swap file. But if once you change the file, the swap file is going to be created.
I am assuming you have a long running vim session like I do (my first window in my screen session is always vim and it usually lives for several days, almost for the entire duration of the uptime). I think the swapfile is not kept around, if you simply close the buffer, unless you have the 'hidden' setting. What happens is that when you have the 'hidden' turned on for buffers, vim tries to keep all the undo history of the buffer, and so has to have the swapfile accessible, in case you come back to the buffer and start undoing changes. As for me, I don't like this feature and keep it turned off (which is the default) and so only have to deal with the swapfiles for those buffers that I actively have loaded in a vim window at the time of crash. Since I have macros that autosave my session every 5min., and since I also disable the Vim's default swapfile detected prompt, restarting my session after a crash is fairly painless.
I am thinking of installing a buffer explorer for vim. Both minibufexpl and bufexplorer have very good rating. Can anyone explain the differences or the pros and cons between them. Or is only a matter of taste?
Thanks!
I've used both of those plugins. I used minibuf explorer for a long while (couple of years) and it was pretty good except in situations where you have large numbers of buffers open. Then it just becomes confusing and starts to take up alot of screen space.
buffer explorer doesn't give you a constant view of what buffers you have open but it's actually a much more solid (less flaky) plugin and when you switch into buffer explore mode it lets you quickly delete buffers you're not using etc. I like it much more now.
Basically, I'd say minibuf if you don't regularly edit more than 8 files. Buf explorer if you edit tonnes of files at once.
i've used both but moved to fuzzyfinder. minibuf gives you a little window to easily switch between buffers and bufexplorer gives you a window you can invoke to call an open buffer.
Now let me sell you on fuzzyfinder, you invoke the window and start typing to match the name of the file that's open. Could be the buffer id or any part to the full path of the file including the file name. Fuzzyfinder also works with your tags file so you can easily jump to any tag within your project. Also works with directories, markers, and most recently used files. It can also open in a split window, tab, or the current window.
I think that using MiniBufExplorer with a lot of files (more than 8-10) is probably not very efficient since it takes a lot of screen space unless you have a big monitor.
I ran into some issues using MiniBufExplorer with multiple buffer splits open at the same time, and I modified the plugin to get around these limitations.
The part that made the plugin unusable was the fact that there was no indication of what buffer the cursor was currently active in, and it was very easy to get lost while switching buffers. I use H and L to move to the previous/next buffer.
I also updated the plugin so that it always reflects the current buffer's state, wether it's unmodified or modified, without having to switch buffers for the plugin to update.
I think these changes really make MBE much more usable, both in terms of the sheer number of open buffers as well as moving between them, which is important.
You can find the updated changes here: https://github.com/fholgado/minibufexpl.vim
I have tried them both and I prefer minibuf. The fact that you have all your buffers and their numbers at a glance allows you to switch to the buffer you want with:
N CTRL-^
where N is the number of the buffer you want to open.
I haven't found any other buffer explorer as fast. However, as Benj said, if you often work with many files you'd better choose something like bufexplorer or selectbuf (a kind of bufexplorer more customizable).
You also can try 0scan plugin. Just press 0b and select buffer or enter tags like dir name or extension of part of the file name to reduce selection list size.
If you selected buffer but it wasn't the only one from the list you can select next or previous after with keys 0j and 0k. Good if you need to switch between buffers from certain dir or with certain extension.
I first tried minibufexpl but noticed some strange characters would show up while in insert mode, like repeating characters when typing a space character or using navigation arrows or hjkl. Then uninstalled and tried BufExplorer, which I like better and the issue of strange charaters was resolved for me. I use vim on both my mac and ubuntu; and had the strange charater issue on both until I removed minibufexpl. My vim setup is here: https://github.com/pixelhandler/vim-config