I like Vim's swap file system and I want to be prepared for the case I forget to :w, reusing this system.
I think it's possible if I can change when Vim deletes the swap file, but I could not find the way firstly to stop Vim from deleting it.
Do you know how to do it? or any alternative?
Related
Sometimes Vim creates a .swp file when I edit something, but not always. Why is that, and what causes Vim to create .swp files? Is it bad to disable them in .vimrc?
Vim creates .swp files for recovery. In case you fail to save, vim will be able to recover (at least some of) the file.
The merits of disabling them depends on what you do. If you use vim for anything that has a build, you probably save your sources all the time (how much time goes by between your coding stuff and compiling, building, and running a ut? Probably not hours). I hate the swps because they always require me to tell the version control system to ignore them.
I have weird issue with vim - for some files it doesn't color the syntax and opens it readonly mode by default, even if I use sudo. chmod for this file are 664, I am also owner of this file, so normally i shouldn't.
I have no set ro in my vimrc.
I noticed also that it often happens after removing .swp for this file - unfortunately, after this, this particular file is every time opened in readonly mode. One idea is - maybe is this some kind of spf13 cache?
For other files the behavior is correct.
Anyone knows this issue?
I found solution - it was more trivial than I expected.
I read the vim messages more carefully and I saw at the end:
if you did this already, delete the swap file `~/.vimswap/urls.py.swp`
So i did small investigation and i found .vimviews inside my /home directory. I just removed it's content and ...it works!
Probably spf13. There are WAY too many problems caused by spf13 in my opinion. Try doing :verbose set readonly? when you see the problem, to see where it happened from. My guess:
I think I remember spf13 having some kind of automatic session management built in, this would restore 'readonly' on a file if it had ever been set on that file.
It is quite possible (a fairly common solution) that if spf13 detects an existing swap file, it will automatically open the file in readonly mode, triggering (1).
It is also quite possible that some autocmd or another related to (2) sets an empty filetype or syntax, which would likewise be remembered by (1).
If this is the case, you can probably find the session file causing the issue (using that :verbose set readonly? command) and delete it.
Also consider, whether you really need all of spf13, or if you could achieve your desired configuration easier by installing plugins and configuring Vim yourself.
How can I restore a vim file from the undo file without hitting undo?
I had a vim file that I saved while adding text. Then I ran a python command that emptied the file's contents, and I can see some of the words the file contained in the file's .un~ file. When I try to undo in the file, it says Already at latest change. I can't find the swap file in my swap files directory.
As the other answers have noted, you can't recover the whole file from vim's undo files, simply because vim seems to only keep diffs in the undo files, not the whole contents. (That makes a lot of sense, as it's space efficient.)
One thing you can try though, is to extract what's possible from your undo file:
$ strings <undo-file>
The output will not be pretty, but you could end up finding something that's valuable to you.
You can't. The undo information is linked to Vim's last knowledge of the file's contents; when they don't correspond any more, Vim cannot re-apply the changes. This is documented at :help undo-persistence:
Vim will detect if an undo file is no longer synchronized with the file it was
written for (with a hash of the file contents) and ignore it when the file was
changed after the undo file was written, to prevent corruption.
Best you can do is try to manually salvage recognizable bits in the undo file, e.g. with a hex editor, or Vim's binary mode.
It is not exactly possible, as the undo file only contains the text that was changed in a single change. If you at some point reloaded the file, the undofile should contain the complete buffer for that and starting from there one could theorectically recover the file (by going through the undo states).
I have written about this before at the vim_use mailinglist here and here (which even contains a patch, that let's you force reading in the undo-file)
You could try to patch vim and see if you can recover at least some data.
A reminder that if you have set in your .vimrc file
set backupdir=$HOME/tmp
You may have temp copies of the files that are readable and that can be renamed
I am trying to determine if a vim read-only instance can open a file, to detect changes.
I am developing a method of forging a minimap-style functionality in VIM running in Konsole (KDE terminal emulator). I am having trouble syncing the two views. My line of thinking is that I might use a marker, but I need the map view to have access to the main view's markers. Is there a way to open an already-open file with the -R flag (readonly) but have it read the existing swap file to be notified of new markers?
Thanks!
I could not see a way to do this, and tried using a simple text file and two processes trying to edit the same file, with one Vim process invoked with -R.
Using gVim -- never tried with command line vim -- it is notified when a change takes place, but not because another vim process made the change. In other words, CVS might update a file I am editing, and I'm asked whether to ignore or reload, but two vim processes did not have that file open.
I did some more work with this, and using -R and 7.2.330 and I was able to edit one file regularly and the same file using vim -R. When I wrote out the file with a change, the other file did not see the change. gVim did see the change when made.
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.