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!
Related
I was watching an online tutorial by tutsplus , during one of the lessons, the teacher started to move between buffers using :bn :bn :b#, but he forget to mention how to load files into the buffer before talking about navigating between the buffers, I searched and find that using:e filename or :o filename would load a file into the buffer.
So, what is the difference , I can't understand the document explanation provide within vim.
The difference is that you shouldn't use :o, which is a useless artefact of vi compatibility, and use :e (or one of its alternative) instead.
From :help :o:
Vim does not support open mode, since it's not really useful. For those
situations where ":open" would start open mode Vim will leave Ex mode, which
allows executing the same commands, but updates the whole screen instead of
only one line.
Just… forget that command even exists.
FWIW, even the vi specification is pretty vague about what open mode is and does.
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
Problem:
If the file "tmp.rb" has been modified, the command "e tmp.rb" will fail.
I'm seeking for a command to succeed in both following conditions:
If "tmp.rb" is not in the buffer list, the file will be loaded;
If "tmp.rb" is already in the buffer list and been modified, the
buffer will be loaded(in current window).
Clarification:
Sorry for all the misleadings. Indeed a single command e tmp.rb will achive both as long as the modified "tmp.rb" is not loaded into the current window, in which situation I prefer e tmp.rb does not cause an error and has the same effect as b tmp.rb. Maybe this little concern will make scripting around buffers, windows etc. a little more easily.
The :edit command fails when the buffer is already loaded and modified to prevent you from accidentally overwriting the changes. If you do want to override, use :edit! instead. In many Vim commands, an appended bang (!) forces the command. Alternatively, if you want Vim to ask you for confirmation, use :confirm edit.
I couldn't reproduce your problem.
What I do to try reproduce your problem is
Open tmp.rb with vim, write some thing and save.
In other shell,
$ echo > tmp.rb
Enter :e or e: tmp.rb in vim and it reopen the file without any problem.
If other program is accessing the tmp.rb at the same time this other program maybe are locking the file and because of it you are having the trouble you describe.
The title of your question says "OR" but its body says "AND".
Vim's commands are usually very precise, it's rare to see an ambiguous command that does multiple mutually exclusive things. The number of keys you can use to enter insert mode (iaIAsScCoO) is a perfect example of this.
You should use the appropriate command for each situation:
:e tmp.rb
:b tmp.rb
If you don't mind installing plugins, CtrlP's :CtrlPMixed may help you with its nice abstraction.
I know that I can close all opened buffers in vim by :qall.
I want to close event to pending opening buffers.
I have problem while reviewing my changes in P4 sandbox. When I have changes in multiple files and I try to review my code with "P4 diff" and set my P4DIFF to vimdiff.
It opens one by one vimdiff of all changed files. Now if I have 10 opened files and after reviewing 2 files I want to close diff for remaining 8 files. How can I do that?
Thanks,
This sounds like a job for hastily learnt Vimscript!
Particularly, the :bufdo, if, and match statements!
Try out the following:
:bufdo if match(expand("%"), ".vim") >= 0 | bw | endif
bw is for buffer wipe in Ex-mode (the : operator)
expand("%") returns the name of the current buffer
match(string, pattern) finds the index of a pattern in string
|'s separate lines if you're in Ex-mode
This matches buffers that contain .vim in their filenames and closes those buffers.
I'm guessing if these are temp buffers that are fed into vimdiff, they wouldn't have file names to begin with. Maybe you can use bufnr(".") to output the number of the current buffer. Then you can close all buffers past or before a certain number.
You can probably do even more buffer manipulation with certain plugins. I've been considering adopting one of the following three plugins that help manage plugins:
LustyExplorer
FuzzyFinder
minibufexpl
I can't speak for any merits, but I've heard them mentioned several times over the internet and on IRC.
I'm assuming you open vim with a number of arguments (known as... the argument list).
You should probably reset it:
:args %
You can also selectively manage the list (:argdelete). More information: :he arglist
DISCLAIMER: I've not used perforce, so I've had to make an assumption: that when multiple files have uncommitted changes, it will behave like a lot of VCS's and run the configured diff command (in this case, vimdiff) on each changed file in turn (I'm thinking this is what you meant by "opens one by one vimdiff of all changed files").
If this is the case, then vim won't have any references to any of the remaining files when viewing the changes for any particular file, so no amount of trickery within a single vim session is going to help you.
If you are willing to change your workflow at all, you may be able to do something with this vim script I found: http://www.vim.org/scripts/script.php?script_id=240
It claims to be modelled after the P4 GUI, so hopefully could fit neatly into your usage. From the overview of the script, it sounds like it should be able to show you a summary of which files have changed and allow you to view the changes.
If none of this is suitable for you, you could always try the old favourite Ctrl-C immediately after closing a vimdiff session for a file.
This is a bad hack but putting it here as no other answers worked for me.
Add "qall" without qoutes on top of your .vimrc .
:e ~/.vimrc
:source ~/.vimrc
:q
All files will close automatically after opening.
Then open vimrc in emacs or sed and remove qall.
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.