While the information in there is good, a bunch of the settings are now redundant¹. The ones that jumped out to me were esckeys, ruler and showcmd.
Not that I'm saying you can't — or shouldn't — re-set options, just that the linked documentation is a little dated. FWIW, I personally re-set a couple of default options mostly so that I have a point of reference for how an option works when I'm digging about in my config.
I'm of the opinion that the combination of recent vim and Tim Pope's sensible.vim² is The Minimal Setup™.
¹ The site says the last update was 2014, and back then $VIMRUNTIME/defaults.vim wasn't a thing for example(7.4.2111).
defaults.vim was and still is an abject idea that we sadly can't get rid off, now that it has been there for a few years.
The least desirable property of defaults.vim is also present in sensible or in system-wide vimrcs written by package maintainers: you get a black box where things are added/changed/removed without your knowledge or consent. "Your" so-called minimal setup is going to evolve over time, but not according to "your" needs.
We got so many support request related to that silly mechanism that's not even funny.
Same here. Vim's new "default" to tie middle-click paste to vim's buffer rather than the X selection drives me up the wall, every time. It's not just that I have multiple machines to administer, it's that there's multiple users (roles) to configure separate things. And for every user my default workflow is now broken.
I've given up on vim. I'm now teaching myself Emacs on my own machine, and replace vim with neovim everywhere I can.
I also agree in theory, but Ben McCormick's ~/.vimrc is tiny and is easy to understand for newbies, so I'm OK with it.
But yes, adopting the rule that you should never put anything in your ~/.vimrc that you don't understand from building it up over time and usage is a good one.
I definitely get how looking at someone else's vimrc could be considered interesting but someone else's config is an expression of their own circumstances, that are very likely to be different from yours. Yes, picking up something that makes sense for you and that you understand _can_ be a win, but a) it doesn't replace actual learning, and b) using someone else's vimrc wholesale is not. All you get is a damn black box that you don't understand better than Vim itself… and yet more commands to learn. That's a losing strategy.
As for Ben McCormick's vimrc…
- line 18 is useless and its comment is misleading
- line 30 is a matter of taste so it has nothing to do in that context
- the comment for line 33 is wrong and shows how much the author cares about "new vim users" and how much he knows about the subject
Building one's vimrc from scratch is an integral part of the learning so shortcuts are to be avoided.
One of the things that annoys me about default vim (nvim more exactly) behavior is that it shifts the cursor left when exiting Insert mode. I use this to disable it:
Aside from the advice mentioned (I bind caps to escape), I find that beginners use escape waaaay more often than is necessary because they aren't using all the commands at their disposal. For example, entering insert mode to delete some characters instead of using d+motion or x. Or entering insert mode to add indentation instead of using the = operator. It would take too long to enumerate all the cases where there is a much more streamlined way to perform an operation than entering insert mode, but I think this would explain the difference in experiences between people that may have used longer and aren't bothered by escape-use frequency and newer vim users.
First I “live” in command mode and only visit insert mode to …insert stuff afterwards which I always leave with escape.
So using vim becomes a series of small edits.
I map caps to Ctrl and use Ctrl-[ for escape.
That means I can still use Ctrl for insert mode shortcuts such as
Ctrl-w (delete last word)
Ctrl-r to insert a register (eg Ctrl-r% for filename)
Ctrl-h instead of reaching for backspace.
There’s loads of them.
It just takes a bit of muscle memory but if you’re a touch typist it’s well worth it IMHO.
Doing it this way, rather than say ‘jk’ in insert mode, also has the advantage of working in other vim-like programs where you’d have to repeat the mapping. If that’s even possible.
I’ve never found a problem with it. Right at the corner, it’s easy to hit with my left ring finger, sitting perfectly at a comfortable distance (based on where I rest my hands) for a slap in that general direction.
(I use my Caps Lock as Backspace. Backspace near the top right is vastly less comfortable to reach than Escape in the top left.)
That’s how I use Escape too in Evil Emacs/Spacemacs. There is some funky default in Spacemacs where you can hit something like d+f in rapid succession in order to enter normal mode but I didn’t find it to be worth it.
People really like the home row but (1) I think it is fine to leave it once in a while and (2) my joints don’t like stay in a very static position for too long in any case.
Disagree with Esc being in a good spot but having dabbled with the "workman" keyboard layout can confirm its quite lovely having backspace as caps. I often wonder about making capslock backspace, and original backspace becoming Escape. Since I already have strong muscle memory to stretch to backspace...
We simply do get used to that and all the rest. The benefits of modal editing far outweigh the eventual clunkiness of pressing a given key now and then. But the more you know how to use Vim, the less you need to get in and out of insert mode and the less you need to hit <Esc>.
I've been using this mapping for so long and it's so ingrained in my brain that I completely forgot about it. It used to happened that I'd start typing jjjjj into a textarea or a word processor, and it took me a while to realize what was wrong.
Doom Emacs had this behavior by default, and it caught me by surprise when it prevented me from typing "noto-fonts-cjk." I knew a lot of people do this in Vim, but it took some time to figure out exactly what had happened. Excellent framework though.
You can map both jk and kj to Esc, which will allow you to press both of them simultaneously. Then you can set your timeout quite low when in insert mode.
Its the weakest part of the vim keyboard scheme IMO for ergonomics, and switching modes in general. I wish there was an alternative that gave a nod to vim but remained in 'input' mode without loss of capability, you know...without having to be vscode. If the key layout wasnt even worse, and it wasn't a bloated mess (on windows at least) I'd have switched to Emacs. Capslock is mostly a redundant button so I wholey support remapping it and for me is the only sensible way to use vim, binding to jj is hacky and plays up often and is inefficienct, and ctrl+] is insanity for such a regular press. Caps as Esc is useful in games when remapped to esc too for speedy pausing or simply pressing it by accident to kill you in a gunfight lol struggles
> I wish there was an alternative that gave a nod to vim but remained in 'input' mode without loss of capability
Problem is, without modes, we lose capability that comes from the fact that modes exist, such as simple characters being compositeable commands;
How should a non-modal editor know whether that [d] I just pressed is me wanting the letter `d` or the delete command? It can't;
Either I have to somehow tell it "the next letter I press is to be interpreted as a command", or "interpret what I press as commands until I say otherwise". The former gets tiresome rather quickly (what if I have to do several commands?), the latter would again be a modal editor.
If you want stay in insert mode most of the time you could use Ctrl-o to switch to command mode for a single command and then be immediately returned to insert mode.
Eg
Ctrl-o de
To delete to the end of the current word.
Again, I definitely wouldn't do it that way but vim makes pretty much everything possible.
I wish Ctrl+[ wasn't tied to Esc. I hit that often instead of Ctrl+P. Haven't yet found a way to map Ctrl+[ to Ctrl+P without affecting behavior of Esc as well.
It's because your computer can't tell the difference. c-[ and ESC send the same key-code. Same with c-i and tab. What you can do to get around this is to remap one of them to something like f20 using Karabiner, then map f20 to what you like in vim.
Can recommend interception-tools mentioned in that SO link. I have been using them for quite a while, remapping caps to escape in desktop environment agnostic way.
Esc is probably the easiest key to hit in the keyboard? Tied with bottom left ctrl/fn and whatever you have in the other two corners. As in it's the easiest to misclick without accidentally hitting other keys
The easiest are F and J, the home keys where your index fingers rest. The more you have to "reach away", the harder it is to always correctly reset your hand.
I'm not advocating for that! Just that Esc/Mode shouldn't be far. Vim uses Esc for mode switching because the author wrote vim on a keyboard that had Esc where now Capslock is on a modern keyboard.
I use ctrl+c. Since I'm already used to ctrl+c while using a terminal, it became easy even in vim.
By default vim goes to normal mode when you press ctrl+c
I mentioned in another comment that I used to do this, note there are some rare cases when it's not the same as esc. You can remap Ctrl-c to be exactly the same though.
Caps Lock being Esc is so convenient that I use Esc a lot more outside of Vim too. Stop the browser loading a page? a quick pinky tap on the caps lock. Take the focus out of a text field (so I can use my Vimium commands)? tap the caps lock. Decide not to save or open that file after all? caps lock's got your back.
The remapping was originally for Vim, but now at least a third of my Esc usage is outside of it.
Agreed! But it's a frustrating experience when you find when a website or application doesn't implement Esc for what you find to be nearly standard behavior across other applications. E.g., it seems like 80% of lightboxes allow closing via Esc.
Time. It slowly becomes second nature and now I quickly reach for esc in many applications, not just vim. It does seem weird at first, an insert key (i, a, o, etc) and an esc needed for every text addition, but over time you grow used to it.
I also have my caps mapped to both ctrl and esc. Ctrl when held, and esc when tapped. Wish I had done that ages ago.
I remapped caps lock, to be control when you hold it and escape when you use it alone.
However, for a long time I used Ctrl-c instead of escape, which is 99% the same except in some odd corner cases (not recommending that, just mentioning my history).
These days I use the common vi tweak of 'jk' being mapped to escape.
I've just got used to over time. It's gotten to the point I accidently use vi keybindings in other applications. Luckily there's keybindings in common applications e.g. typing / followed by a search phrase works in Firefox as it does in Vi which is pretty cool.
On my Ultimate Hacking Keyboard I have a mapping of (left)space+q to produce Esc which for this combo I hit comfortably with my left hand thumb + ring finger.
On other keyboards I find fishing for the Esc key with the left ring or sometimes even middle finger good enough since it's so prominently singled out on the top left corner on all the keyboards I had yet to use, but it breaks the flow a bit more.
It probably helps that I'm not typing in proper form for the 10-finger system but only some hodgepodge approximation of it...
I use either karabiner on my laptop or map it in my keyboard firmware (mostly drive QMK boards for the last few years) to swap caps lock to escape on tap and control on hold. Makes vim life great. Also means that using ctrl+a as a tmux leader is comfortable to type.
Do you consider hitting enter/return for a newline to be clunky as well? Its generally the same size as caps lock and opposite it on the keyboard. I'd say I press return a bit more often then Esc when using vim, but its close
I use a programmable keyboard with thumb keys, similar to the ergodox. I have escape set to one of the thumb keys so that it's no more work than hitting "space".
Not a great answer, but I switched Cap with Esc and it took several months before I was hitting Esc automatically like you might Ctrl + s a document when stopping typing.
Many decades ago, you had to resort to abbreviations so that you could use memory in the most efficient way possible. Computer hardware at that time was more expensive than labor. People having to adapt to how computers worked was the doctrine at that time.
But in 2022, this is no longer true. Even the most limited platform you can think of can comfortably run vim. A $5 Raspberry Pi Zero is overkill for vim. And now, labor is more far more expensive than hardware.
So, economically, having commands like "set ek" are objectively a waste of resources. Make commands self-explanatory, drop the abbreviations, and just add autocomplete and suggestions to compensate for the verbosity.
It's time to evolve. The reason this page exists, is because vim is unintuitive. But it doesn't have to.
Quite apart from the fact that many (most?) vim short forms have long form equivalents, and vim has autocomplete - this argument feels misguided to me, mostly because I don't see why it would be limited to just vim. It seems natural, if you hold such a position, to also advocate abandoning CLIs like `ls`, `cd`, `jq`, `aws`, et al? - and I would despise having to put up with stuff like:
Not to mention short parameters: `ls -AF`, `grep -v`, `curl -H`, ...
One of my most valuable resources is time. I would rather invest it in learning each tool's vocabulary than spend so much time typing (a prefix longer than the existing name, tab, then pick the answer) in an "everything is spelt out in full, acronyms and abbreviations are banned" world.
> Make commands self-explanatory, drop the abbreviations, and just add autocomplete and suggestions to compensate for the verbosity.
Vim has autocomplete. That said, while I support long commands, I like having short commands because it's less typing, and I use vim on awkward keyboards where it matters. Also, any changes need to leave the old way or you break people's muscle memory (so again, just add the friendlier versions in addition, not as replacements, and I'm probably on board).
I use macros way more often than dot. With a macro I can include the movement action of getting to the correct position before the edit takes place, I'm not sure if this can be done with the dot key alone.
Whether one uses . or a macro (manual or recorded) should depend on the current situation. It's really not a "pick one and stick with" it kind of situation.
I agree, so many ways to do it it’s horses for courses.
Eg from the first “pick” you could press * to highlight occurrences and move to the next one use cw to change it to “s” and bounce on n to move to the next one you to squash and use . to repeat the change.
That’s visual and lets you decide which commits to squash.
If I wanted to squash all the other commits I’d probably use visual block and } instead, but that’s just me.
For a case like that, I'll use rectangular block mode--it's really fast and intuitive, so I'll usually pick that over :s/a/b/g if it's applicable.
The whole thing would be something like <ctrl-v>5jecs<esc>. Ctrl-v starts rectangular block mode, go down 5 lines and to the end of the word, change selection to "s", return to normal mode.
to replace "pick" at the start of line with "s" on all lines?
If you execute it once in vim you can recall it later with just typing
:%↑
and confirm with Enter.
As for the top of the file:
gg
I use the mnemonic "go go line" (as in Inspector Gadget's "go go gadget") and since you can prefix it with a line number (e.g. 4gg to go to line number 4), leaving it out gets me as close to line number nothing^Wzero as possible, i.e. line 1.
HTH :)
PS:
the % says "on all lines"
your trailing "/g" would make it match&replace "pick" multiple times on the (current, since % is missing) line
PPS:
As an aside, I use "vim somefile +N" all the time to open somefile at line number N;
especially when there's an error message in the form "error at somefile:N" by
typing vim, then double-click-middle-click copy&pasting "somefile:N", Ctrl-E to jump to the end and replacing ":" with " +".
I really should write a shell function for that...
> Shift+G takes me to the bottom of a file, but I don't know how to get back to the top :D
I know the complement to Shift+G, it's gg. But I can never remember which one goes to the top and which to the bottom, so half the time I press both. :)
Thank you everyone for the _really_ helpful responses!
It is immediately apparent to me that my interaction with vim has been heavily informed and limited by my preconceptions and previous text editing experiences.
Time to start engaging with vim as its own entity, with its own conventions and idiosyncrasies.
G takes a line number as its "object" like other vim commands. So 1G is the first line, 10G the tenth, etc. G is the last. (0G goes to the last line too.)
The only thing I've really struggled with when trying to get into using vim full-time is navigating my project. In VSCode I basically hit CTRL+SHIT+F -> "portion_of_a_function_name_or_something" constantly. I abuse the heck out of global search. Is there a way of navigating your project in vim that's similar/easier?
How do vim people quickly navigate their code without going "what was the name of that file with that function"?
Historically, people used :grep and the quicklist to jump between project files based on abitrary strings and Ctags to generate a language specific index of functions, variables which you can jump to.
These days people generally use some kind of fuzzy finder plugin thats basically the same as the vscode experience. Exactly which one you use depends on various factors, but Telescope and Fzf are two big names and both allow searching through a bunch of other stuff, setting names, edit history etc. (You can also save the fuzzy search results to the quicklist so you've basically got a reusable index).
And neovim is heavily embracing the LSP paradigm, where you'd use something like gd to jump to definition when on top of a function and a language specific LSP server will tell Neovim where to jump to.
> And neovim is heavily embracing the LSP paradigm, where you'd use something like gd to jump to definition when on top of a function and a language specific LSP server will tell Neovim where to jump to.
This x100. I switched to neovim+pylsp a few months ago, and it's been an absolute delight. I use lspconfig [1] and pyslp [2] since most of my time is spent developing Python code. Not only can I navigate more quickly and easily, I also find myself catching more silly errors before run-time due to better linting from the lsp.
It used to be that I wouldn't use vim beyond quick edits on single files. Although I still prefer to use vim style bindings in IDEs, I can go much further before I feel the need to fire up an IDE in the first place.
Vim supports ctags[0] lookup out of the box which fits your need somewhat.
I tend to use FZF[1] which has functions for leveraging ripgrep and silver surfer for searches. It can also use find. FZF also has dialogues for paring down results in real time (i.e., as you type)
There are also plugins that are much more nuanced and more involved for searching symbols and providing autocomplete. Duoplete, vimcomplete, youcompleteme spring to mind.
I use neovim now and have switched my search over to using Telescope.nvim which is a fuzzy search basically.
It lets you do pretty much what you say allowing me to type <leader>-f and partially type things to remember where I am with a preview pane. Seems moderately fast most of the time for the monolith I work on.
Vim has the concept of <cword> and <cWord> (you can :h <cword> these for more info), which are basically the things that vim will jump across when you press 'w' or 'W'.
You can combine this with grep and the location list to find symbol usage across multiple files.
nnoremap <leader>g :grep <cword><CR>
You can then use :cnext and :cprev (or focusing the window and selecting an entry) to navigate between them.
As others have stated, you can also use ctags (plugins like https://github.com/ludovicchabant/vim-gutentags are useful for refreshing tags in a project), but for some languages you may need to add a tag definition (e.g. for something like rust or zig). For older languages like C you should be fine.
Worth noting that :grep can be configued to use ag, rg, ack or git grep which can add some modern conviences like respecting prohect specific ignore lists and there are plugins that build more on top for each specific tool.
I prefer VsCode these days - but every now and then a Vim macro is needed - the rare case where multiple cursors won't cut - I just C-p Open in Vim [1]... for fun and saving a few minutes (not always)
For me, minimal setup means installing on a fresh machine.
At this point, my vimrc automatically installs plugins if they're not installed.. otherwise it's one command. So it's just copy/paste and maybe one run command, and then vim environment is exactly the same on the new machine (it auto downloads).
I found it pretentious on first read. The first feature: `nocmp` is not explained well enough and is vague. What is buffer in `hidden`? Not beginner friendly. As a neovim user, I haven't had the need to all these settings.
Not that I'm saying you can't — or shouldn't — re-set options, just that the linked documentation is a little dated. FWIW, I personally re-set a couple of default options mostly so that I have a point of reference for how an option works when I'm digging about in my config.
I'm of the opinion that the combination of recent vim and Tim Pope's sensible.vim² is The Minimal Setup™.
¹ The site says the last update was 2014, and back then $VIMRUNTIME/defaults.vim wasn't a thing for example(7.4.2111).
² https://github.com/tpope/vim-sensible