
Vim is a fast and efficient text editor that will make you a faster and more efficient developer. It's available on almost every OS, and if you master the techniques in this book, you'll never need another text editor. In more than 120 Vim tips, you'll quickly learn the editor's core functionality and tackle your trickiest editing and writing tasks. This beloved bestseller has been revised and updated to Vim 8 and includes three brand-new tips and five fully revised tips. A highly configurable, cross-platform text editor, Vim is a serious tool for programmers, web developers, and sysadmins who want to raise their game. No other text editor comes close to Vim for speed and efficiency; it runs on almost every system imaginable and supports most coding and markup languages. Learn how to edit text the "Vim way": complete a series of repetitive changes with The Dot Formula using one keystroke to strike the target, followed by one keystroke to execute the change. Automate complex tasks by recording your keystrokes as a macro. Discover the "very magic" switch that makes Vim's regular expression syntax more like Perl's. Build complex patterns by iterating on your search history. Search inside multiple files, then run Vim's substitute command on the result set for a project-wide search and replace. All without installing a single plugin! Three new tips explain how to run multiple ex commands as a batch, autocomplete sequences of words, and operate on a complete search match.
Remembering Clippy[0], I have written a snippet for .vimrc that gives me a random advice (hint / feature / hack) when starting vim. It is not certain that I will need it here and now, but at least I will refresh my memory, and maybe I will be tempted to try it and internalize it during the session.
Many (at least half) of the hints are taken from Drew Neil's wonderful "Practical Vim". Highly recommended!
The hints are written in a terse manner. If you are new to vim, few of them will enlighten you on the spot. But the others might still pique your curiosity. Just explore further using :help... or read "Practical Vim".
The idea is that eventually you will curate `vim_hints.txt` on your own, adapting it to your needs (and your memory).
And the VimL Primer[2] by B. Klein
But Vim is a whole culture that starts with ed(1), the standard editor. You do edit based on line numbers and regex addressing and commands. Then there was ex(1) that added more features. vi(1) added a `visual` mode to ex(1), and some commands can now be done in relation to the position of the cursor. Vim is the improved version of vi(1), a lot more commands and a scripting language.
The plugin system is similar to everything that was unix at that time, relying on a variable like $PATH. Any path added to that variable (runtimepath for vim), should follow some patterns for subdirectories and the file will be loaded according to a certain logic. Plugin managers actually manage that variable and do a few things aside (isolating plugins, downloading from forges,...)
[0]: https://pragprog.com/titles/dnvim2/practical-vim-second-edit...
[1]: https://pragprog.com/titles/modvim/modern-vim/
[2]: https://www.oreilly.com/library/view/the-viml-primer/9781680...
Not sure what "trivial" is trying to convey here, but in any case personally I would put quickfix list as a rather advanced feature. Like in the excellent book Practical Vim[1] its covered in chapter 17 on 21 chapters.
[1] https://learning.oreilly.com/library/view/practical-vim-2nd/...
[0]: https://pragprog.com/titles/dnvim2/practical-vim-second-edit...
Genuinely, I think the best antidote to this is to refuse to do this until you personally feel about 80% confident you really understand how to work with the thing from the inside out.
Don't try to rewrite Vim until you've already read and annotated a copy of Practical Vim and drove it daily for a few years, for example. Don't try to rewrite SQLite until you've started hitting up against use cases even the common advice online can't help you with.
This means you will probably do very few rewrites. That's intentional - focusing your effort on making new software that solves new problems is, for all those who trash talk it, really much more valuable. And if you ever do a rewrite in earnest you'll walk in with intimate knowledge of what exactly you're trying to do here.
