tpope / vim-obsession

obsession.vim: continuously updated session files
http://www.vim.org/scripts/script.php?script_id=4472
1.75k stars 68 forks source link

Just a question about how you guys handle swap files #18

Open unphased opened 9 years ago

unphased commented 9 years ago

You see, my Macbook likes to freeze a lot. It's not enough to warrant me to be really upset (for more than a few minutes when it happens, as it averages once every 2 weeks) but it's enough that it gives me reason to set up a plugin such as this one.

Now what happens when I go and re-open with vim -S after my machine dies is that I get a flood of "What should I do with your swap file".

How do you guys deal with this? I find that I usually try to mash D, but this is not really ideal for the reason that if I keep pressing D I will eventually start to erase lines from some buffers.

If I don't mash D, say I Recover with R, I am re-presented with the prompt the next time because Vim is just so nice/dumb. Not to mention R will lead me to replace some letter in some buffer with the r character.

The other obvious reason why mashing D sucks is that I'm just actually choosing to throw away any unsaved buffers.

Honestly this wouldnt be problematic if my goddamned fruit machine will just stop freezing up.

unphased commented 9 years ago

Well, something that works when vim refuses to give the option to delete the swapfiles and you want to dispose of them, is

rm **/.*.sw{p,o}
jwhitley commented 9 years ago

I HATE the swapfile problem, and eventually went with this solution:

" Store temporary files in a central spot
let vimtmp = $HOME . '/.tmp/' . getpid()
silent! call mkdir(vimtmp, "p", 0700)
let &backupdir=vimtmp
let &directory=vimtmp

This puts all of vim's tempfile droppings in a single centralized location, e.g. ~/.tmp/<vim process PID>/<files>.swp. If a vim process unceremoniously exits, then you'll have one directory with *.swp files versus having them scattered around your filesystem. The PID of the next vim you start is unlikely to collide with the one that died, so you'll virtually never see the swap file message. You could periodically blow away everything under ~/.tmp with no regrets. If PID collision ever became an issue, it'd be trivial to put some automated cleanup (delete every dir in ~/.tmp for which no PID exists) in place.

This has worked so well that I'd completely forgotten about the entire problem until I saw this issue.

unphased commented 9 years ago

That's awesome! Thanks for sharing your solution, I think it will address this issue pretty much perfectly. Even in the event of PID collision seems like the only thing that'd happen is we get the prompt. Not too bad.

I'm curious though. If we have the same file name found in two different locations on the filesystem and I edit them both in the same vim (say.... the file Makefile), won't this cause their swapfiles to collide under ~/.tmp/<PID>/.Makefile.swp? Or will the swapfile actually get created inside there in a replicated system sub-path? I suppose if this becomes an issue I might as well fetch the path and just make use of it in that mkdir call.

Also, wow. Today I learned about vim backups. Well, I wonder if I should use them. On files I care about I check them into git. And on ones I care about even more, I check their *.un~ vim undofiles into git also. Now I find out that I can make periodic backups... wow. (undo files probably consume less space and are more granular, however, they are probably a great deal more fragile) But being able to make backups and organize them into a single location is just extra insurance for free. I'll take it.

unphased commented 9 years ago

Update: I tested it and it will basically use its own name-collision resolution system .swp, then .swo, etc. Looking inside the file itself shows the files are in a binary format, but it's possible to see some ascii text showing the actual file path. So, no problems there.

Also, holycrap that's creepy, Github cross-references commit messages across repos.