Vim Galore: everything you need to know about Vim
github.com
github.com
Vim and Emacs are an investment, but the investment pays off ten fold. On top of their powerful features you get to support free and open source software that isn't being steered by corporations that want to keep you locked in and collect as much analytical data on your habits as possible. They aren't looking to lock you into an editor as a service. We've seen with neovim that the system works and has made both vim and neovim even better through healthy competition. Free and open source for the tools you use everyday is the way to go.
Apart from the built-in features (like :terminal), somehow I haven't yet explored plugins to enhance my Vim usage. Granted that coding projects over 100 lines are rare for me, I still feel like I should try them out and see if I can get used to them. If not pure coding projects, at least for things like markdown, having a preview could help.
You can use a dedicated app alongside Vim for that. On macOS, Marked2[1] is pretty great.
Avoid the massive omnibus plugin packages. I find they often try to turn Vim into something it's not.
Nothing against people who use and enjoy those -- I'm not advocating for elitism or purism. I just feel like if you really want Vim to look and feel like (e.g.) VSCode, you're better off using VSCode.
Instead, I've gotten the most out of the plugins that I've taken the time to hand-pick and configure myself. Largely because I took that time to understand them.
Plug 'ap/vim-buftabline' " Show buffers in the tab line.
Plug 'derekwyatt/vim-fswitch' " Switch between header and source files.
Plug 'farmergreg/vim-lastplace' " Reopen files at last edit position.
Plug 'fatih/vim-go' " Comprehensive Go support.
Plug 'junegunn/fzf.vim' " Fuzzy finder commands using fzf.
Plug 'liuchengxu/vim-which-key' " Show possible leader completions.
Plug 'majutsushi/tagbar' " Sidebar ctag browser.
Plug 'mbbill/undotree' " Sidebar undo branch browser.
Plug 'mhinz/vim-signify' " Show VCS markings in the sign column.
Plug 'mhinz/vim-startify' " Extendable start screen.
Plug 'ntpeters/vim-better-whitespace' " Highlight trailing white space.
Plug 'plasticboy/vim-markdown' " Extended markdown support.
Plug 'tpope/vim-fugitive' " Vim git porcelain.
Plug 'tpope/vim-surround' " Adds surrounding text object.
Plug 'tpope/vim-vinegar' " Improve netrw.
Plug 'vim-utils/vim-man' " Open man pages in Vim.
Plug 'w0rp/ale' " Lint engine and LSP client.
Cscope is built in (:cs). The kernels I work on have a make target for tags, which is also built in.
You might also like `clangd` and `scripts/clang-tools/gen_compile_commands.py` if by kernel(s) you meant the linux kernel. It's pretty neat!
Everybody's needs are different, of course, but I personally find that Vimwiki [1] gives me all the preview I need, right in the editor, when editing Markdown.
Put together neovim, nvim-treesitter and nvim-lspconfig (which are both "official" plugins), and fzf.vim, and you end up with a decent IDE with only one non-official plugin.
Less plugins = less to go wrong, easier to reason about, less configuration needed, more zen.
This is what I love about Vim. It's by far my favorite editor even with just basic usage, and I consistently learn new tricks that make it somehow even better.
- a: Find assignments to this symbol
- c: Find functions calling this function
- d: Find functions called by this function
- e: Find this egrep pattern
- f: Find this file
- i: Find files #including this file
- s: Find this C symbol
- t: Find this text string
It also has built in makefile and gdb support.
If you haven't done so already, you're encouraged to donate to ICCF Holland :)
Many terminal users will be upset if you change a tool out from under them. Many desktop users don't know how to vocalize it.
In addition, it's more common afaict for cli/tui tools to be open source, so if someone does change a tool out from under you it's possible to fork the old version and keep the UI you like.
A huge issue with this for me is that it is practically impossible to confine myself to the universe where only vim keybindings exist.
* vscodevim extension for Vscode
* "set -o vi" in Bash
* Vim Vixen plugin for Firefox
* you can use ctrl-alt-j in gdb. And that might (should?) work in other programs which use GNU Readline to get vi keybindings. The only thing I miss with the vi bindings in bash/readline is "ge/gE" from vim (move backwards to the end of the word).
These days, on Firefox, Tridactyl is the way to go for me.
And I really like the lightspeed plugin you have in your playlist there. So effective navigation.
I also use neovim session plugins which is great when having several projects.
1) Open a file (in a split) in the same git repo that shows up under 'git status'. I'm way too comfortable hitting ctrl-z, git s, grab mouse, copy, fg, :sp ctrl<v>. Is there a simple pattern/plugin to just list modified files and open one in a split?
2) Open a file in another repo. So I'm in src/foo, and I need to open a file (in a split) in src/bar. I often use NerdTree for this but it feels slow and cumbersome, but maybe I'm using nerdtree wrong? Something like being able to just type <leader><key> <start typing a path and get fzf-style results> or something like that.
3) Find where a function/method is defined in the current git repo. Right now my pattern is I have Ack search (but using fzf) bound to backslash, so I type like \'def funcname' but this feels so cumbersome. Is there a faster way to just say "open the file where the function name my cursor is in is defined"?
For reference, in the shell I tend to rely heavily on fzf and fzf-using functions (e.g. 'vis' will let me select from changed files via fzf and open it in vim, 'vif' will let me select from any filename under the current dir in vim) and I guess I'm mostly looking for bringing that power and flexibility into vim without shelling out or lots of arrow-arrow-return-arrow-arrow-return in nerdtree.
2) I can't really help you there, at least not in vanilla vim. I make heavy use of tmux and never work on my more than one repo in the same vim instance, nor is my vim's current working directory every anything other than the root of the repo I'm in. So if I do need to open a file in another repo and want to see two repos side-by-side (which is rare but it happens), I make a tmux split.
3) gutentags [1] can help with this. Though nothing is better than using a language server for your given language. That said, I still just have gutentags and mostly just grep/search for `def func` like you currently do.
nnoremap <C-p> :FZF ~/src<CR>
I just open the split first, then C-p in the split.
> Called with no arguments, `:Git` opens a summary window with dirty files and unpushed and unpulled commits. Press `g?` to bring up a list of maps for numerous operations including diffing, staging, committing, rebasing, and stashing. (This is the successor to the old `:Gstatus`.) [1]
To open file in split: <C-w>f
2) fugitive works with it too. See this thread [2]
3) I use fzf [3] too. My pattern is a bit shorter: '\r' (mnemonic from '' for search the word under cursor). With the mapping and command:
```
nnoremap <silent> <Leader>r* :Rgw <C-R><C-W><CR> "" <C-R><C-W> - to paste word under cursor in command prompt
command! -bang -nargs=* Rgw
\ call fzf#vim#grep(
\ 'rg -w --column --line-number --no-heading --color=always --smart-case '.shellescape(<q-args>), 1,
\ <bang>0 ? fzf#vim#with_preview('up:60%')
\ : fzf#vim#with_preview('right:50%:hidden', '?'),
\ <bang>0)
```
[1]: https://github.com/tpope/vim-fugitive/blob/master/README.mar...
It's still quite a few commands but the advantage is that you get a buffer where all your commands should operate on $other_repo.
Vim isn’t hard, and it’s faster than everything else.
Vim is the one true editor (except for that other one true editor which is also ok).
it does have a learning curve and took a while to settle down all those key bindings with plugins. once you past that point, it never stands in the way, and I don't need move my fingers away from the keyboard to pick the mouse and click here and there then move my hands back to keyboard anymore.
There are a couple "flavors" of neovim that do a lot of the heavy lifting for you as far as plugin setup to give you a better initial setup experience, otherwise you will need to put in some work to finding all the plugins you want, and some of that work will need to be repeated for each language you want to write.
I spent about 4 months on it daily unable to get up to speed how I was originally.
This may just speak to my own inabilities of muscle memory, and granted, If I used Vim a little younger, I think the outcome would be different.
But the thing is, I'm productive enough.
Furthermore, I found the mouse to be faster in many cases - I only believe the top 10% of vim users who have spent countless hours tailoring their config to be the most "productive" in terms of typing.
I say productive in terms of typing, because when we code, a grand majority of our productivity actually comes from our brain.
Squeezing out additional wpm actually has very little relevance to productivity.
But looking at seasoned Vim users looks cool though, and it definitely does give those style points.
Vim will always be there and because it's not backed by big tech, it will continue to be modular, fast and modern.
Much like Linux, learning it means you are free, powerful and you will not get affected by the whims of big tech. This is very valuable.
Every year you use free software, you invest time in skills that won't go away and will support you for life.
I was pretty happy in TextMate at the time, but the popularity tide had turned as he was working on TextMate2. The writing appeared to be on the wall, so I learnt vim properly. Sublime took over, then came Atom, now VSCode. Neovim is home for me now, and that's been a whole other beast to configure, but vim has just been such a stable, efficient environment for me for almost 15 years now.
Do you have to learn Vscode? no.
Do you have to learn vim? immensely so.
Moving onto the next big thing (although i'm betting on vscode for at least the next decade), is not going to be hard.
If you actually want to take full advantage of the editor and its plugins, then the answer is yes. It's easier to immediately get to grips with vscode than vim, but once you've understood the basics for vim (which takes maybe a full day of studying, and then some practice over a few months), the two editors are pretty equivalent in how much time you have to spend on super-powering them.
I think that's relevant because once you've seen how vim (or emacs) can be customised, it's kinda hard to accept vscode as is, without spending significant time customising it. To me, that makes your argument that it's easy to move to the next big thing, mostly invalid... it would be easy if I don't care about learning and customising the tool.
Of course mileage may vary depending on how picky you are with your setup. I'll admit I lie on the picky end of the spectrum.
One of the most disagreeable things I have ever disagreed with.
If you remove your bias, you'd find it within yourself that you would disagree with your own statement as well.
When the next VSCode comes along, I will move onto it with ease. Please do not ever consider that I'd get onboarded to vim just as quickly - I've spent enough time with vim to know such.
Jesus.
> If you remove your bias, you'd find it within yourself that you would disagree with your own statement as well.
You don't know me, or what my experiences are. So please don't assume that I'm biased, simply because I have a different view than you. Likewise, please don't assume that I would share your view if I just understood things as well as you do.
I maintain a small amount of config files for vscode, a medium amount for vim, and a large amount for emacs+evil. I use all three editors for work, and have done so for years. The thing holding me back from switching to vscode fully is precisely the fact that it would take too much effort to customise it as well as I have customised vim and emacs.
Obviously your experience doesn't agree with mine, and I clearly can't say why. All I can say is that vim simply "clicked" for me when I first learnt it. I have coached enough coworkers that I can say the same thing applies to most people who take the time to learn the "vim way". And of course vim would not be as popular as it is, if that wasn't generally the case.
Perhaps vim simply doesn't speak to you. That's okay, nothing wrong with that.
But it's objectively complete nonsense to claim that vscode does not require a substantial time-investment if you really want to super-power it. And that has nothing to do with the editor, it has everything to do with the fact that the editing experience is highly individual. If you really think you will move onto the next vscode with ease, all that tells me is that you won't take the time to learn the tool.
From my very first comment about the matter.
>>I spent about 4 months on it daily unable to get up to speed how I was originally.
>>This may just speak to my own inabilities of muscle memory, and granted, If I used Vim a little younger, I think the outcome would be different.
You keep talking about configuration, when the bigger elephant in the room is learning the keybindings.
It took me almost 2 months to be comfortable without looking at the vim cheatsheet
It then took another 2 months to get to a speed at which I felt like I could be productive.
And at that point, my typescript projects were so incredibly slow, I had to quit vim.
>But it's objectively complete nonsense to claim that vscode does not require a substantial time-investment if you really want to super-power it.
I still disagree as GUIs makes configurations a lot simpler, and as plugins are just a click away.
Again, if you include learning the keybindings, which for some reason you refuse to, you'd find it within yourself that you would disagree with your initial statement.
This is such a presumptuous and arrogant statement to make.
Not only do I include learning the key-bindings, I also am thinking of customising your own key-bindings. But simply learning the default key-bindings should not take you 2 months. Even if it doesn't click for you, I am convinced you could learn this faster.
And besides, vscode also has a ton of key-bindings. That's one of the very reasons why I haven't gone full in on vscode. Your 2 months to learn vim key-bindings should also take 2 months in vscode, if you approach it with the same efficiency. The way you respond here, I'm starting to think you'd already made up your mind to dislike vim before you tried it.
> I still disagree as GUIs makes configurations a lot simpler, and as plugins are just a click away.
And each plugin also comes with key-bindings and customisability. If you simply install a plugin and leave it at that, then you haven't spent the time actually learning it. Installing a plugin in vim is as simple as adding a single line in vimrc.
2. Vim requires 2-3 dozens of keybindings memorized in order to have a decent feel for the editor, which of 1-2 hours of daily practice took me about 2 months.
3. The productivity gained from keybindings/macros/file navigation is negligible in the bigger scheme of things as it is your brain that does the heavy lifting in code.
I don't think that the utility of VIM comes from squeezing out wpm, but in it's navigational and editing capabilities. Particularly when paired with a relevant language server, code navigation is a breeze. Additionally, being able to run it on a remote server, in a tmux session, means I can drop off and pick up my work from basically any machine without any effort.
My vim config is pretty barebones, its primarily just language server support and git fugitive.
Now, modern vscode setup with a remote plugin, language plugin (and vim keybinding plugin) gets you basically the same benefits. For me personally though, I find a few things more clunky in that setup than the vim version of it, mostly around code navigation.
I agree with your point though; part of the reason I'm always apprehensive about redefining keys is because I'm never 100% sure whose keyboard I'm going to be typing on (though that's less of an issue now cuz of COVID).
(Discovering what that function is and why it’s important is left as an exercise for the reader).
Any time someone says this, I think of [this comment][0].
[0]: https://www.reddit.com/r/vim/comments/2c3cuu/a_quick_tour_of...
For making changes in a single small file, vim is good enough and I enjoy using it. But any time I find myself dealing with bigger changes and multiple or big files (Stuff that is more "Project" scope rather than "Code" scope, if that makes sense) I always feel like I want to be using VS Code instead.
Plus once you figure out org mode and magit you can't imagine living life without them.
(Also as a humrous aside I just tried finishing this post by typing :wq! because of force of habit, I love vim)
Can't say it made me any faster or more efficient, but it sure does feel satisfying and more comfortable. And, let's be honest, it also makes me look cool!
Once you learn them, there is nothing to think about; that's the beauty. It's muscle memory - I swear (I haven't tested with an EKG) that the signal doesn't enter my conciousness, like an old violinist playing.
Yes, that only applies to things I use regularly, though they can be easily combined into larger commands. I'm not at all suggesting that things I use once a year go to muscle memory, much less all of Vim (probably only Moolenaar knows it all)!
- Native Lua support. While you don't have to rewrite your config in Lua, it's a big boon for plugin writers.
- A very active community, fueled by.Lua being so much nicer than vimscript.
- Native LSP support. Granted, you can get similar features from plugins such as coc, but the native integration in Neovim feels a lot more integrated and extendable.
- Treesitter support. Fast and more detailed syntax highlighting is nice, but you can also do more contextual transformations like swap functions or function parameters regardless of formating.
I also actually like vimscript—Sure, it's 100% Stockholm Syndrome, but still.
Some people seem to love the lua angle to neovim, I don't really know anything about the language, I get that it allows for more powerful stuff, but it's also ugly as hell and it seems like it always takes like 34875982345 characters and 700 curly braces to just do imap jk <Esc>....
But as basic plugins that will provide a great quality of life, I shall recommend those:
Global Search: fzf
Syntax Highlight: nvim-treesitter
LSP: nvim-lspconfig or coc
Dir Nav: nerdtree
Git: vim-fugitive
Finding files is much faster with a fuzzy file finder, and displaying the file tree (which I think people typically need way less often) can be done by backgrounding the vim process to drop to the shell, running `tree`, and foregrounding again.
One is most likely to conclude this when using an IDE and wanting to juggle some prose in a comment. What would have been so simple in vim is a little bit harder in your Monaco based editor. A happy environment is one where vim is never far away, no matter what you are working on.
But yeah, overall it's an excellent combo.
Command mode sucked but it's much better now. If I could close the results window with an escape character, that'd be just great.
If you navigate right with the space bar, it screws up the line. Right arrow works fine. However, I think this is a VSC problem. :e! fixes the problem.
If you do any editing immediately after opening, it just inserts your keystrokes at the beginning. It would be better to buffer or ignore them. I also think this is a VSC problem. :e! fixes the problem.
I only added clangd very recently. It obviates You Complete Me, ctags and much of clang-tidy. It refactors. It's an awesome code navigator.
https://clangd.llvm.org/features
I still use neovim from the command line occasionally. But since they've fixed command mode, that's less and less.
> If you like "Y" to work from the cursor to the end of line (which is more logical, but not Vi-compatible) use ":map Y y$".