Can't really say enough good things about Vim. I retired early as a staff software engineer because of the work I did using Vim. From hacking silly games in C in high school to now, I've always been able to use Vim and run circles around any "modern" text editor or IDE. I feel like I owe Vim as much public praise as I can give so others can reap the rewards like I did.<p>What really frustrates me is how little people seem to want to invest in their tools, or the outright lies they tell themselves about how much configuration they need to use Vim on a daily basis. My Vim config is 200 lines, and my last commit was 3 years ago. I've invested maybe a few days of my life into configuring Vim and I use it 8-16 hours a day.<p>Vim can do so much on its own. It has autocomplete, fuzzy finding, integration with build systems, file search, navigation using a directory browser, jump to symbol, parse compiler output to jump to bugs, support for gdb and breakpoints, a built in terminal, copy to and from the system clipboard, and with literally 8 lines of code you can get support for every linter, LSP, etc. known to man, fuzzy finding, and git integration that let's you use native git commands with seamless editor integration.
> sorting and reversing over motion<p>Vim can run shell commands as filters over selections as well.<p>Although vim does provide its own `:sort`, you can also sort the current selection like<p><pre><code> v{motion}!sort
</code></pre>
Which uses the external sort command (coreutils)<p>For reversing,<p><pre><code> v{motion}!tac
</code></pre>
Which uses `tac` to reverse the order of the lines.<p>This general concept is quite useful in many other ways, since it is quite universal - selection goes to stdin of arbitrary program, stdout of that program replaces selection.<p>For example, if you want to quickly test a function that takes a json string, and you're in a language where instantiating good mock objects and serialising it takes quite a bit of code, you can quickly make a mock by writing JS code within the string quotes and have the code console.log json and then `vi'!node` will replace it there.
The Vim configuration is something deeply personal, but I'd recommend as a wise choice always explore first the default settings because assuming those in your workflow gives an huge advantage using any new unconfigured vim environment eg to get out of any of the edit modes <C-c> works by default and is a great choice.
To use CUA alike shortcuts there's already:
```
source $VIMRUNTIME/mswin.vim
```
And finally, is also a good idea to get used to use <Leader> as a prefix for your own shortcuts, in my case I use the space bar as <Leader>.
I had no idea Vim had a terminal mode with ':ter|:terminal'! Definitely something I'll look into to improve my own Vim + Git workflow. I've usually just moved Vim to the background with Ctrl+Z, done my committing, and then moved Vim back to the foreground with 'fg'.
<i>I often use the :wa command to save all my open buffers. But it has the nasty habit of throwing an error when it’s not able to save all buffers</i><p><pre><code> nmap <F2> :silent! wa<CR>
</code></pre>
<i>Copy to System Clipboard</i><p><pre><code> if has('unix')
set clipboard=unnamedplus
else
set clipboard=unnamed
endif
</code></pre>
Also, to type word under cursor into command line:<p><pre><code> cmap <M-w> <C-R>=expand("<cword>")<CR>
</code></pre>
Paste without replacing clipboard (for the lazy):<p><pre><code> vnoremap p P</code></pre>
> This articles looks an awful lot like a list of Vim tips<p>honestly, I like articles that are “a list of vim tips”. I can usually find some really good ideas that I didn’t consider. The tip about remapping copy to system clipboard to something easier than ‘“+y’ is genius, definitely using that.