A Good Vimrc (2014) | Hacker News Reader

A Good Vimrc (2014)

dougblack.io

298 pointsbasename53 comments

I don't believe it's possible to have a good vimrc without really grasping some elementary concepts like movements, operators, registers, windows etc. I have recently watched all the Drew Neil's VimCasts[1] and after just a couple of hours I've realized I was missing a lot for at least 10 years. There is also quite a good presentation on YouTube by Max Cantor "How to Do 90% of What Plugins Do (With Just Vim)"[2]. Instead of treating a single vimrc as the best one it's useful to skim through dotfiles and plugins of some influential vim users like Drew Neil[3] and Tim Pope[4]. BTW VimCasts are accompanied by a book. The second edition[5] includes changes introduced by Vim 8.0.

[1]: http://vimcasts.org/episodes/ [2]: https://www.youtube.com/watch?v=XA2WjJbmmoM [3]: https://github.com/nelstrom/dotfiles [4]: https://github.com/tpope [5]: https://pragprog.com/book/dnvim2/practical-vim-second-editio...

I would also recommend Daniel Miessler's tutorial.[1]

[1]: https://danielmiessler.com/study/vim/

+1 for the Max Cantor presentation - I mostly use stock vim now because of that video... also you can get a lot of mileage from combining :read with shell commands. I like this approach as it forces me to level up my bash.

> Don't put any lines in your vimrc that you don't understand.

Actually true for most human-configurable setting files.

I sort of disagree with this and think one should extend in the opposite direction- to keep sharp, have an RNN generate some plausible config options / shell commands, and append them to the bottom of your vimrc / bashrc on startup. This results in sort of like a 'chaos monkey' of coding, to prepare you for when real emergencies pop up.

Huh? The point of a Chaos Monkey is to simulate failures that might happen in real life. How does this do so?

Don't tell me you've never accidentally rm -rf'd something important

Don't tell me your default method for deleting files is to carelessly throw 'rm -rf' at the issue...if it's "important" and you're using -rf, a part of me thinks "you deserve whatever happens"

I was joking in both comments (clearly running arbitrary shell commands on a personal computer is a terrible idea), but it's not like a careless rm -rf has never happened before

Oooh, I really like this idea.

Well when I did a vimrc there was no single line in my vimrc that I really understood. VimL reads like output from a keylogger.

Actually, VIM remaps _are_ little more than the output from a keylogger! A keylogger recording a VIM session, no less.

Well... Yes. It's the same command language that's used to drive vim by hand, so it should resemble a keylog of doing those actions.

I wonder why text editor preferences are so personal. I use the same editor and probably 90% of the same config as this guy and was nodding along until I saw he remapped B and E. Horrifying! Those are fundamental motions.

I’m always surprised at the number of people who recommend mapping `,` as their Leader key; it’s almost as useful as its counterpart, `;`. I suspect that such people never learned vanilla Vi and use `f`, `t` and related line movement commands.

When I learned Vim, I started with the `vimtutor` tutorial. At the end of the tutorial, it suggests Learning the Vi Editor - by Linda Lamb (O’Reilly)[1] for further reading. I found this book to be excellent for providing a solid grounding on Vi – and its descendants such as Vim. For a while, I constrained myself to using Vim in Vi-compatibilty mode before using the many wonderful features provided by Vim.

I try to keep my vimrc as lean as possible so that I’m not reliant on having it available (even though I have it in a Git repository on my VPS) and it’s only in the last couple of years that I’ve started adding plugins to it (Syntastic and Unicycle).

[1] http://shop.oreilly.com/product/9781565924260.do

"I’m always surprised at the number of people who recommend mapping `,` as their Leader key; it’s almost as useful as its counterpart, `;`. I suspect that such people never learned vanilla Vi and use `f`, `t` and related line movement commands."

I've been using vim for years, but I completely disagree with your statement. I rarely find the "," key useful, so to me it was a no-brainer to switch to using it as the leader. I just have ",;" mapped to the functionality that "," used to do.

I use ";" all the time, but searching backwards just barely comes up. Usually, I'll hit "home" and then repeat my "f" search if I need it.

Thanks for different perspective (and to otterpro and tasuki). I use `;` much more often than `,` but I still find the `,` useful when I’ve gone past the position I want to go to, e.g., typing `5fx` when I should really have have used `4fx`.

> I’m always surprised at the number of people who recommend mapping `,` as their Leader key; it’s almost as useful as its counterpart, `;`. I suspect that such people never learned vanilla Vi and use `f`, `t` and related line movement commands.

I use `,` as Leader, as well as to search back if I happen to `;` over something I was looking for. I don't mind waiting 400ms (my `timeoutlen`).

I agree that we shouldn't use "," or ";". I prefer to use SPACE as the leader key, as it is probably the most prominent key and also easiest to reach, but I can understand why some would use "," or ";" because of it's easy reachability and the fact that those keys aren't as used as often (at least for novice users). Perhaps it should be part of "best practice" in Vim.

I was listening to a recent TalkPython podcast with Dougal Matthews titled "Effective Code Reviews". Host Kennedy asks every interviewee what is their favorite editor. Dougal's answer: (44:35-44:48) "I use Vim all the time. Yeah, I work in so many remote servers and VMs that I have some scripts to kind of set up my Vim environment on that machine, and then it's just great."

Who knew it would be that easy to switch to your own personal VIM setup?

It is easy once you have put in the hours (days? months?) learning what you need and then scripting the setup... :)

The literal worst of vimrc is the _default_ settings of many Linux distributions these days. Colors are fine, but _behavior_-changing stuff is not. I would be happier if package installers included a brief configurator as part of installation.

Do you want to use tabs when you press tab, or spaces? If spaces, then _how many_?

Do you want to automatically (infuriatingly IMO) continue comments and completely wreck the ability to paste text without also _telling_ vim that you intend to paste via the `set paste` command?

Simple stuff like that, you know?

Ahhh good old 'set paste'. The setting that has turned away so many. When I watch a novice coworker struggle with vim, the breaking point usually comes when they try to paste directly into insert node. That may be the most valuable of all commands in this discussion.

Does vim 8 still not have bracketed paste by default?

https://cirw.in/blog/bracketed-paste

Bracketed paste appears to be a third party plugin. I have no reason to believe it is has been rolled into an official Vim release.

Tabs vs spaces should be a per-project setting, not per-user setting. For that: http://editorconfig.org/ (there's a vim plugin: https://github.com/editorconfig/editorconfig-vim)

I've been using VIM for a while, and I'm always delighted to read articles or examples of good .vimrc's, but this one tops them all, because of the perfect balance of cool features and concise explanations. Good job, OP, what a wonderful blog post, I learned a couple nice things too!

Now just add the section about uploading it to your GitHub so all new servers get setup with a simple git clone, and any new changes can be propogated around with push/pull.

For anyone interested in this topic, [0] contains the best setup I've found for storing dotfiles in a git repo, then linking them with GNU Stow. Steps are just:

  git clone https://github.com/me/my-dotfile-repo
  cd my-dotfile-repo
  stow --target=$HOME zsh
  stow --target=$HOME vim
  ...

Elegant, cross-platform, easy to remember.

[0]: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

I second this and highly recommend using stow for this. It takes all of 30 seconds to learn, took me maybe 10 minutes to round up my various dotfiles and move them into a central folder, and, combined with putting them in a VCS, has made life sooooo much easier.

Sorry if this is a super naive/dumb question, but why wouldn't I simply write a "build" script that copies files out of my dotfile repo to where they're supposed to go?

1) It's cumbersome, and you'll need to specially handle things like deleting files. I personally wouldn't be comfortable having a homebaked script rm stuff in my home directory.

2) By using copies instead of symlinks you'll need to run your script Everytime you make changes and be careful to edit only your clone instead of the target location.

The copies get out of sync, if you edit ~/.vimrc instead of ~/projects/dotfiles/vimrc you will have a hard time keeping all of your systems in sync.

Replace copies with links and you are golden. Yeah, you can write a simple script to create those links for you, but Stow seems pretty full featured.

I switched over to Stow last time I set up a new machine and now regret not having discovered it long ago. It always amazes me how for basically any problem you might have there's probably a GNU project to resolve it.

Wow, this is fantastic. I just repo'd all my dot files and used Stow to set them up. Very elegant indeed! Thank you!

https://dotfiles.github.io

I use the approach from https://news.ycombinator.com/item?id=11071754

I keep my dotfiles repo on a vps where I manage the repos with gitosis.

Since this article is written in kind of a "literate programming style", I'll plug and share my Emacs config that is actually written in literate programming: https://github.com/munen/emacs.d/blob/master/configuration.o...

Nice documentation like this fine blog post for free^^

If I understand it correctly you generate the program from that file by removing all the non-code text, right?

This is very well documented , but not "actually" literal programming. It's a losing battle over this definition but since you said actually I'll go for it one last time :p

In literal programming, the order of the explanation dictates the flow of text. Conversely, well documented source code follows the order of the program.

The literate programming paradigm, as conceived by Knuth, represents a move away from writing programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts.[2] Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code.

- https://en.m.wikipedia.org/wiki/Literate_programming

Literate programming in this specific case would include a big overview of the entire file somewhere with references to each section. These would then be pulled in and included at compile time.

> In literal (sic) programming, the order of the explanation dictates the flow of text. Conversely, well documented source code follows the order of the program.

org-mode supports noweb-like chunks, so you can do "real, Knuth-like" literate programming. It just makes little sense in the case of configuration files because they're just a collection of mostly-independent bits.

Since configuration in Emacs mostly is code, imho it makes a lot of sense.

It's code, but most of it is simply (use-package ivy ...) or (setq tab-width 3.14), where's the value in chunks? The typical Emacs configuration doesn't contain data structure definitions, algorithm implementations, or error handling that can be more appropriately reorganized for a reader.

Thanks for sharing your opinion, but your premise is flawed. Through org-mode litaerate programming is indeed not only possible, but a great option.

If you're interested in that area I encourage you to give it a try.

This article would have been much better with screenshots.

Good write up. Ive been looking into Now this might sound like heresy but I've been considering moving to emacs lately and using evil mode.

The thing that gets me is vim's lack for auto completion for stuff like scala. Has anyone managed to set that up?

Have you checked out [ensime](http://ensime.org/)? Should solve the problem for you.

I'm in the same place right now.

Did the emacs fundamentals tutorial. Installed evil. Got a little frustrated when some things didn't work exactly as expected. Also there is a weird TLS bug with the melpa and marmalade repos and the packaged emacs that debian stable offers. If I need to compile something then Neovim starts looking more attractive (I'm not aware of any package for debian stable atm but am happy to be corrected).

Now I'm just looking to try to solve my problems in vim again :)

https://github.com/neovim/neovim/issues/2211

There are packages for Jessie at the very least.

Have you considered spacemacs? http://spacemacs.org/

I've been using it for a month or so. It's very easy to set up and configure, and it's built with evil-mode in mind. It also has very good modes for development - I use it for Go and everything including completion and hinting function signatures worked right out of the box once the Go layer was installed (which is one line in your .spacemacs)

My problem with Emacs, I'm a bit of a visual person and Emacs doesn't have tabs. There's all sorts of half baked tab system that don't do what the real thing in Vim does.

And everytime someone I ask about this someone point me to some "superior paradigm". It ain't superior if I don't like it :)

I think I have got tabs allright in my emacs, although a tab-layer would be definitely appreciated in spacemacs

My Chrome on Android is getting a certificate error for this website.

The best vimrc is no vimrc at all.

Reply on news.ycombinator.com