I accidentally deleted my .vimrc which took me weeks to config. I still keep the undofile and I think that's the only way I can restore it. Unfortunately, vim now does not allow me to undo (I guess because my current vimrc version cannot be "patched" with the last undo step).
Also, vim undo file is encoded so I cant see its content in human readable form. There was a step where I just deleted all my vimrc with ggvGc and so if there is a way to decode that vimundo file, I think I can restore it.
Is there anyway I can get my vimrc back? Thank you.
For people coming here years later, it's not possible in recent versions of Vim.
You could try running this to extract what you can from the undo file:
$ strings <undo-file>
See Recover a vim file from the .un~ file without the undo command for more information.
So, as FDinoff suggested, the patch here really works for me.
Related
I am a new comer to the vim world, and I have just installed spf13-vim for a quick start. Apart from that I have not touched my .vimrc file.
I mainly use vim to write some python scripts on a remote server, so I have to type 'set ft=python' each time I open a file using vim. I am wondering if it's possible to edit my .vimrc file to make python a default choice of vim.
Another confusing thing is that each time I type a blank in vim, it shows a inverted question mark on my vim screen. I think it's because of some mismatch in file encoding, but I have no more idea about it.
I know it's a stupid question, but right now I can't solve it myself. Any help is appreciated.
Edit:
I have solved the problem of setting python default by write 'set ft=python' to my .vimrc file. (I didn't know contents in .vimrc are commands in vim) But I still don't know how to eliminate the inverted question mark when I typed a blank char, even after I do some search.
Name the buffer you're editing from the start, don't forget the :filetype plugin in your .vimrc and then things will work correctly.
In any way having :set ft=whatever in your .vimrc is twice wrong. First it'll apply to all new sessions opened without a file. Moreover it'll only apply to the first buffer. I.e. it won't work with :new.
I was reading :help :edit but I really don't understand the following sentence:
This is useful to re-edit the current file, when it has been changed outside of Vim
And what does start all over mean in :help :edit!?
This is useful if you want to start all over again
Could anyone please provide some use cases of them?
"Changed outside of Vim" means that the file that you're editing has been written to by another program. :e will load the latest version, and :e! will do that even if you have unsaved changes.
Loading the current file from the file system is useful if you're following a log, or viewing a generated file that gets updated when you run :make and other situations.
One use for this is to throw away the changes you've made since the last save with :w and go back to the most recent saved version. Which is to say, it's not necessary for the file to have changed behind Vim's back for this to be useful. Although Vim has enough undo depth that you can usually undo your way to back to the unmodified state, it's cumbersome. You can easily "overshoot" and then have to redo. The status line shows you whether the file is [Modified] or not, but as you undo, it gets overwritten with information about each undo, so you have to use Ctrl-G to re-display the file status.
I had no idea :e by itself with no argument did this re-loading, by the way; I have been using :e% for years!
Let say I have messed up my vim & tmux configuration. Is it possible to delete or reset them without losing any configuration changes such as PATH etc? If so, then how?
At this point? There probably is no way to get those files back. But, as a preventative measure in the future, keep config files like those in some sort of version-control system (like git or mercurial).
However, if this is too tedious or you don't want to for whatever reason, you can also add the following lines to your .vimrc:
set undofile
set undodir=~/.vim/undodir
Don't forget to mkdir ~/.vim/undodir.
This configuration enables persistent undo history in vim (I assume you're using vim to edit these files). With this feature, even after you close the file, and reopen it, you can still undo changes you made in the previous editing session. So if you'd had this set, your problem would be solved simply by hitting u until the files were in a good state. See :help undofile for more info.
Also, check out the great plugin vim-mundo. It provides a visual "undo tree" and makes browsing vim's complicated undo history very easy. Plus it's compatible with neovim.
I had a file open with gvim and it asked me if I wanted to reload the current buffer because it detected a newer version of the file. I accepted, but it turns out the new buffer is not what I want. Is there a way to recover the old buffer? The file on disk (and the swp file, which I viewed with vim -r) contains the new buffer) unfortunately.
If your buffer had fewer lines than the 'undoreload' settings, then its content will be stored in the undotree just before it was reloaded. This means, that a simple u or g- should get your buffer contents back. A plugin like my histwin plugin or the famous Gundo or undotree plugin could be helpful as well.
Note, this needs a Vim of at least version 7.3 or newer to work. Older Vims didn't store the buffer state on reloading.
Try u (undo; if you’ve made changes since reloading, repeat until the old version shows up).
I am in terminal Vim, but I don’t think that should make a difference here. I opened a test file with Vim in one terminal tab, went to a new tab and edited it there, saved that, switched back to the first tab, ran :e to reload the file, and then switched it back to the last version I had opened in the tab with u.
I have something like this is my .vimrc
" Backup stuff
set backupdir=~/.vim/backup
set directory=~/.vim/swap
set undodir=~/.vim/undo
I can help with cases like this were you accidentally overwrite your local changes and you want to find your old version of the file. Make sure to create the directories first to avoid errors on startup.
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.