Does vi support "confirm on quit" - vim

When typing fast, I sometimes accidentally type :wq, when in fact I just wanted to :w. Obviously, this causes a major pain when I have a session with numerous files and I end up losing all my buffers and have to reopen those files one after another in a new session. Just wondering if vim supports a "confirm on quit" feature that can prevent me from shooting myself in the foot.

Easy solution: put set confirm in your vimrc. If you want more customization, consider writing function like in this plugin: https://github.com/vim-scripts/confirm-quit/tree/master/plugin

Related

how to reset Vim & TMUX dotfiles

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.

Disableing Vim's folder view

When I enter Vim's folder view I always enter trouble, as you can see here.
Is it possible to simply disable this folder View?
So that I never have to enter it again by accident.
And if so, how do I do that?
The "folder view" is provided by the netrw plugin (cp. :help netrw-intro-browse) that is included in the default Vim installation. You can disable it by putting
:let g:loaded_netrwPlugin = 1
into your ~/.vimrc file. However, your real problem is bad :autocmds that do not handle so-called scratch buffers (i.e. artificial buffers that do not correspond to an actual file, but are used to display plugin functionality). You'll probably encounter similar problems with other plugins, too, so rather fix or remove those autocmds! Disabling netrw is just working around the problem.

Open vim tab in new (GUI) window?

I'd like to move the current tab into a new (visual/real) window in MacVim.
It's probably difficult, as:
there is nothing in the vim help and only very few - not helpful - hits on google
MacVim does not support it (link, 2009)
So I am wondering if someone has found a way to achieve this?
The closest I think you can come is using mksession
This will have several drawbacks (like, initially the secondary session will open a few more buffers than ultimately desired).
However, it will preserve your mappings, settings, history, window layout (if you had multiple windows inside the current tab, they will all get cloned).
If this idea tickles your fancy, you could look at creating a script that will filter parts out of the session file (which is Yust Another Vim Text Script)
:mksession! $HOME/detach.vim
:tabclose
:silent! !gvim remote --servername Detach -nR +'silent! source H:\detach.vim' +tabonly
save all current windows, mappings, settings (:he mksession)
close the tab we are about to detach
clone the session (detach.vim) into a remote vim
:silent! (try not to talk too much)
!gvim remote --servername Detach; launch a new remote Vim server if it doesn't yet exist, or talk to the existing server named Detach
-nR TODO Fix This is here to avoid the use of swapfiles (because I found no way to suppress the dreaded ATTENTION messages[1]). However, this may be unsafe advice depending on your situation, which is why I also include -R for read-only mode
+'silent! source H:\detach.vim' +tabonly -- In the remote vim, source the session to clone, and keep only the active tab (that was already closed in step 1.)
A little rough around the edges, for sure, but quite close to what you intended, I feel.
If you are comfortable, you can drop the -nR flags and just click through a few annoying swapfile attention messages (keyboard: Q).
[1] :he ATTENTION
Post-scripts:
on windows you might want to use :silent! !start /b gvim .... in case you have terminal windows sticking around
also on windows, you might get annoying behaviour if the resulting gvim window is too small. The :simalt ~x sequence is one hacky way to maximize the window (assuming English UI, because x is the accelerator for Maximize)
as icing on the cake, vim 7.3 has 'persistent undo'. See e.g. :se undofile
I don't think this is possible because, when you open a new instance of (g)vim you don't have access to the undo-history of the previous vim instance. All you can do is (in command mode):
:!gvim %
It will open the current file in a new instance of gvim. At least this is all I could think of. I may be wrong

How to see the last few keystrokes in vim?

Sometimes I hit the wrong keys on my laptop's small keyboard, and odd navigation or editing occurs (sometimes a feature that's new to me).
Although I can undo the editing (u) or navigation (control-o), I don't know what I did wrong, so it's difficult to avoid it in future. It's also frustrating to not know what just happened. So, I would like to be able to see my last few keystrokes.
A bit like :set showcmd, but to show the literal keystrokes, and (ideally) a short history of them.
I've only found commandline and navigation history in help/google.
To clarify: I'm not looking for commandline history, but keystroke history. e.g. did I press ) accidentally and go to the next sentence? Did I press dd and delete a line? I guess it's similar to a keystroke logger.
Commandline history (:history) only shows commands entered at the : prompt.
A bit old, but I've just found this on reddit:
You can start vim with the -w flag to write all keystrokes in a file. See :h -w
vim -w filename
To my knowledge, the closest you can get is the q command, which records your keystrokes into a register of your choice. Obviously, that has to be set up a priori as it's intended for complex repeats, although you could probably hack something to start recording on every file open. There's the matter of memory usage and that annoying "recording" prompt though.
Probably the most straightforward way would be to install keylogging software. I don't have any personal experience with these, but the security implications are probably mild if you get it from a trustworthy source or build it yourself, set it to only log to memory not a disk, only have a buffer the size of a sentence or so, or only log for vim windows.
More recently I came across a logging plugin for Vim and it reminded me of this question:
http://wolever.net/~wolever/wiki/vim-logging
It basically records everything you do for later analysis, it was intended for getting statistics about command usage but should work perfectly for finding what those magic commands you accidentally entered were.
:history will show your command history - that should help you uncover the new features that we all uncover in vim with misplaced keystrokes.
Gundo - Is probably worth a look, whilst perhaps not exactly what you are looking it will help slightly.
It lets you visualise the Vim undo tree, this means you will be able to see the last edits that happened. For example if you accidentally deleted a line or some such this will show up in the tree, however, it doesn't show you the actual keystrokes that were pushed and will not show things such as cursor movements.

Vim: Maintain the history of a file after it has been changed and reloaded

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.

Resources