Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
unphased opened this issue Dec 26, 2014 · 4 comments
Open

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

unphased opened this issue Dec 26, 2014 · 4 comments

Comments

@unphased
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

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 added a commit to unphased/vim-config that referenced this issue Jan 14, 2015
@unphased
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants