Vim – Minimal Setup Explained | Hacker News Reader

Vim – Minimal Setup Explained

guckes.net

213 pointstodsacerdoti111 comments

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).

² https://github.com/tpope/vim-sensible

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.

Every time I use vim on server that doesn't have my .vimrc file that I copy around I inevitably end up googleing "disable mouse in vim"

:set mouse=''

Looks like you should look it up, too.

I took a second to see who the "we" is in your last sentence. The site vimways.org is unusable because its certificate has expired.

Also, amen. Having used vi since before vim, I actually have a few settings to restore vi features and quirks that I like ( cpoptions+=vxZ!$- ).

Yeah, I know about the certificate issue but the person who can fix that appears to be unreachable. I hope it will be settled soon.

See also `:h defaults.vim-explained` (https://vimhelp.org/usr_05.txt.html#05.3) which now comes by default.

You can either copy the settings you are interested in or source it entirely in your vimrc file:

    source $VIMRUNTIME/defaults.vim

---

Here's some more related resource links:

* stackoverflow: useful .vimrc tips - (https://stackoverflow.com/q/164847/4082052)

* vi.stackexchange: How do I debug my vimrc file? - (https://vi.stackexchange.com/q/2003/1616)

* vim-sensible - (https://github.com/tpope/vim-sensible)

* minimal vimrc for new users - (https://gist.github.com/benmccormick/4e4bc44d8135cfc43fc3)

* Vim Configuration From Scratch - (https://marcgg.com/blog/2016/03/01/vimrc-example)

* vimconfig: generate `.vimrc` by selecting options - (https://vimconfig.com/)

Please, no. Someone else's vimrc is the last thing newcomers need.

I sort of agree. When I was first getting into Vim, reading a couple of well documented vimrcs really helped me out.

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.

RIP Sven Guckes. I remember finding this page very helpful. Thank you.

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:

    au InsertLeave * :normal `^

That goes along with this:

    set virtualedit=block,onemore

Question for Vim users: how do you get used to hitting Esc very often? I know some switch Cap with Esc but still clunky.

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.

I've bound it to double J in my vim configuration file. First thing I do on every computer.

how is using cap clunky? works great

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.

I use `jk` or `jj` instead of esc. Its so much easier

   imap jj <ESC>

I tried this, but it (understandably) caused a delay whenever I typed j alone in insert mode

Yeah, you get used to that.

It only matters if you are tying "jj". If you are typing "just", it's just as fast and the "delay" is just visual.

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.

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.

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.

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.

Once I found out CTRL-[ did the same thing I haven't hit ESC since.

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.

Thanks. Not sure if Karabiner is available for Linux, but I found https://stackoverflow.com/questions/41364833/karabiner-for-l... which might help me.

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.

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.)

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...

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.

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.

well, we can’t really have F be a special key to return to normal mode

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.

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.

Now I wouldn’t do this myself but…

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.

  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 actually use Ctrl+[ instead of escape. It takes some getting used to but it's easy to reach

Rebind Caps Lock to Escape (or as a second escape). Can't live without it now.

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

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.

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.

Thanks. This is helpful. I never use those shortcuts and yes most of my Esc are for indentation and deletion.

Indentation is a good example where insert mode isn't needed. Just do stuff like 5>>

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.

I don't. I use Ctrl-C instead.

Caps as Esc works like a charm outside of vim too!

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>.

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...

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.

Muscle memory. It feels clunky at first, especially when coming from a non-modal editor, but I hardly realize I am even doing it any more.

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.

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.

Ctrl + [

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".

I type using my old Sun keyboard still. The escape key is where the tilde key is on normal US PC keyboards. So the pinky stretch is quite easy.

(Also the control key is where the caps lock is. Also another fine position.) :)

It’s pretty easy if you don’t think about it too much.

Esc ? Never. Got so used to Alt-l

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.

> 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).

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:

    $ change-directory foo/bar
    $ amazon-web-services elastic-compute-cloud describe-instances
    $ javascript-object-notation-query ...

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.

Looks just like Powershell.

which interestingly enough can also have things abbreviated, ie Invoke-Web-Request can be used as iwr.

Yes, but they all have shorthand aliases.

When writing a script or documenting you use the long form, when using a shell you use short form.

Welcome to the cargo cult hell that descriptively named all the things.

It’s just me but I think it’s still worth knowing the abbreviations just in case you want to type them.

Personally I try to avoid mappings as much as makes sense.

So I’d use

  :noh

to clear highlighting instead of making a nohighlight mapping for it.

Simply because it’s still quick to type from muscle memory and more portable. I also find them easier to remember than custom mappings.

Why did you write "2022" instead of "two thousand twenty two", and "$5" instead of "five dollars"?

Autocomplete doesn't cut it. You end up hitting "tab" more times than it takes to just type out a two or three character command.

Since I was in university 15 years ago I promised myself to learn Vim commands seriously.

Well I see that finally I did my programmer life learning only switching insert mode / edit mode, maybe 5 commands like A x etc...,and :q or :wq!

Please learn dot ".". It repeats the last edit action. It's so powerful.

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.

I’d save a macro for more complex edits.

I relate quite heavily to this when using vi to do all my git-related activities.

git rebase -i ...

followed by

↓dw ↓←dw ↓←dw ↓←dw ↓←dw ↓←dw i s ↓s ↓s ↓s ↓s ↓s

because I keep forgetting :s/pick/s/g is a thing

i, a, :q, :wq, dd, xdd, and D are all the ones I remember, but cutting/yanking pasting is still something I don't have the muscle memory for.

Shift+G takes me to the bottom of a file, but I don't know how to get back to the top :D .

I really need to make time for vimtutor and commit to it.

> Shift+G takes me to the bottom of a file, but I don't know how to get back to the top :D

mostly emacs user here, but when I'm on vim I use :0 and :%

I'm guessing you want

:%s/^pick/s/

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:

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...

EDIT: formatting

Vim has some built in support for that syntax

https://github.com/Konfekt/vim-compilers

> 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. :)

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.)

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.

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.

EDIT: Formatting

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"?

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.

The only catch with this is that it's neo vim only. It works incredibly well and can fuzzy find lots of things not just files.

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.

[1]: https://github.com/neovim/nvim-lspconfig

[2]: https://github.com/python-lsp/python-lsp-server

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.

[0]: https://ctags.io/

[1]: https://github.com/junegunn/fzf.vim

Yep that’s what I do too. ctags are fast and low overhead to generate.

The other alternative is to set up a Language Server (LSP) for navigation and you can use the same ones as VSCode uses.

+1 As a fellow global search fan, FZF + the silver searcher is the way to go. You just type `:Ag <your string>` and you're done.

Yup. FZF is where it's at. :Files to jump to a file, :Rg to search around for some content.

I also keep vinegar around for when I want to poke around at the contents of a directory.

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.

‘:!ctags -R’ and ‘:ta function’ (or ‘^]’ for the identifier under the cursor). Works well enough for me, even in Real Vi (TM).

My “minimal” setup is nothing. I just use vim the way it is, out of the box.

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)

[1] https://marketplace.visualstudio.com/items?itemName=jonsmith...

Doesn't the VSCode vim plugin support Vim macros as well?

I think it does - at least the NeoVim one should.

(But I feel like I'm faster with regular VSCode - multi cursors easily solve many "text editing" problems that Vim solves with macros/repeat/regexp)

TIL: nocp is so much shorter than nocompatible :-)

I just really really wish my minimal comfortable setup would not need to include

set mouse=

on all "newer" machines/vim versions :-\

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).

Another take on this: https://github.com/sheerun/vimrc/blob/master/plugin/vimrc.vi...

You can use it as plugin

Found the post pretentious

Did you not like the style, or the content? Do you have a better alternative to suggest?

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.

Reply on news.ycombinator.com