>It seems like vvv is slower than vp but in practice I don’t need to think beforehand what to select, and what key combination to use.
The way I've always used vim and always thought it was intended to be used is that you do think beforehand. You sit at your editor, think about what changes you want to make, and then key in a set of precision commands in vim-editing-language and it happens.
>This way v replaces viw, vaw, vi", va", vi(, va(, vi[, va[, vi{, va{, vip, vap, vit, vat, ... you get the idea.
I kind of like the precision of having all of those different things, and of course the option of using them for more than just visual select but also change, delete, and so on. Although I suppose this doesn't remove any of those keymappings, I must protest remapping Ctrl+v: I can't even use an editor without block select.
I imagine there's a plugin (or even builtin feature) that at least generalises "s, (s , [s, tags and things of that sort though.
>Stop that stupid window from popping up: >map q: :q
I know it's a weird and irritating thing to have that window pop up when you meant to quit, but it's actually a very neat interface: a whole vim buffer for recomposing commands and your command history for later execution (almost acme-like). Give the poor guy a chance.
As a counterpoint to what I've pointed out above, I'd like to recommend Drew Neil's [Practical Vim](http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...) to anyone who hasn't read it already. It's got a lot of great content, and really goes a long way to explain vim's quirks and methods of doing things.
One of the useful tips I learnt from that was the ex command "normal", which allows you to execute a string of normal mode commands over a range of lines. So, for example, you can append a semicolon to each line in a visual selection by entering
:'<,'>%normal A;
http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...
A whole book of tips
Links for the lazy (non-affiliate)
http://pragprog.com/book/dnvim/practical-vim
http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progra...
The better you get at Vim the easier it is to learn more Vim.
If it's not fun, then it's probably not worth it. It really depends on what VIM can do to improve your current workflow. So, you may need to drop the VSCode mindset while you start using VIM.
> but now that I’m trying to navigate medium/large projects,
I actually have trouble navigating large projects in VSCode. The buffer, tab, window model that Vim uses makes more sense to me (but it's unique to VIM afaik, so it may be jarring at first). Combine that with a fuzzy finder[1] and it allows:
- rip-grep to search for files with text / file names
- Searching through currently currently opened buffers
Whenever I have to use VSCode (mainly for the live share feature, I find myself pretty lost with VSCode's tab based interface (I usually end up with like 20 tabs cluttering my workspace, and tabs are local to a split, which is jarring for me).
> the vim endgame looks like
It never _really_ ends. Some VIM features that I miss when I use another editor are:
- Really nice integration with terminal commands. One thing that I do very often is copy the name of the current file: `!echo % | xclip -sel clip` so I can use the filename as an argument in a terminal split (running tests for example)
- Filters (`:help !`) so I can pass parts of a file in to a program that accepts standard input. Example: `'<,'>!jq` to prettify bits of JSON.
- Global commands and macros. VSCode vim supports them, but I've noticed that they can run pretty slowly.
- The buffer, tab, window, model (probably the biggest one I miss when I start using VSCode)
For LSP support, I've tried to migrate to neovim's native LSP tools, but I still find COC to be a lot more intuitive. You should feel right at home with it since a lot of the plugins are similar to their VSCode counterpart.
If you'd like a really general and guided tour of VIM, I'd recommend picking up Practial Vim[2] It really helped me understand the workflow a bit more. Approaching VIM with the mindset of another editor wont give you all the benefits of using VIM. Though, if the workflow doesn't click, then that's not a big deal. You can always go back to VSCode.
[1] https://github.com/Shougo/denite.nvim (many people use Telescope: https://github.com/nvim-telescope/telescope.nvim) [2] https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...