There is a religious movement within the Vim community which emphasizes purity of the environment and rejects superfluous plugins and advises adherents to meticulously prune their .vimrc to keep it nearly empty and thus clean from impurities. I personally do not agree with this philosophy, but I do see a point in it. Sometimes having too many plugins might lead to conflicts and weird behavior. That said not all plugins are created equal.
Some, like the infamous Unite plugin are expansive and complex because aim to be kitchen sinks and fountains of utility. Others are tiny and follow the unix philosophy of doing only one thing, but doing it well. Today I would like to talk about three of such tiny plugins that you might find worthwhile additions to your web design toolkit.
The first nifty little plugin adds a feature to vim which I see requested and asked about all the time. Most modern IDE’s or editors aspiring to be developer tools have built in auto-completion for common block and scope identifiers such as parentheses, braces, square brackets and quotation marks. As you open a brace, the editor automatically inserts a matching close brace character on the other side of your cursor. This is exactly the functionality offered by vim-AutoClose.
In the example above you might notice that after I typed the keyword test( and the plugin automatically added the matching ) my cursor next leaped behind it. This is because I actually hit the ) key and vim just skipped the character. This is by design. The author likely realized that auto-closing brackets could easily break the flow of your typing, unless it allowed you to over-type on top of what it inserts. In other words, you can completely ignore that this plugin is enabled and type as you would normally do and all will be well. Only every once in a while you will be spared typing a few characters here and there as it will automatically close the scopes for you.
That’s it. That’s all it does. There is no configuration, no key-bindings and no side effects. It simply auto-closes brackets and quotes for you. It will work everywhere, though the most obvious benefit is in C style languages that use a lot of braces, and brackets.
Speaking of closing things, one of my least favorite things about HTML is closing tags. It is just a lot of extra typing that’s basically busywork. Some IDE’s actually try to spare you that extra work, by adopting auto-close approach like they do with brackets and braces which may or may not be something you want. Other tools, like the editor built into WordPress offer a button you can press to close opened tags at your leisure which is much less intrusive. The Closetag plugin offers you just that: an extra button for closing tags:
As you can see above, I have a bunch of nested HTML tags and all I have to do to close all of them is to hit Ctrl+_ (that’s control and underscore character) three times to close all of them. Each time this combo is pressed, vim searches for the nearest tag that is not closed and generates a matching pair. It works even if your text spans multiple lines, and it wisely ignores tags like <br> which do not need to be matched.
Vanilla vim lets you use the % key to jump between opening and closing brackets or parentheses. It lets you rapidly move around C style code bases, but it does nothing when you are editing HTML. The Vim-MatchIt plugin extends this functionality to HTML files and lets you use % to jump between opening and closing HTML tags:
I’ve been told that this actual plugin gets included by default in many mainstream vim distributions these days. I had it in my plugin directory for ages now, so I just carry it around just in case.
There you have it: three super-minimalistic, unobtrusive plugins that do not change much int terms of core behavior, but add a lot of convenience into your workflow. What are some of your favorite tiny vim plugins? How about Emacs or Sublime people? Let me know in the comments.
To compare with Emacs, each of these features ships with Emacs some way or another.
For pair balancing there’s electric-pair-mode. That’s pretty simple, though, just inserting the matching closing character automatically. There are much smarter pair matching modes available separately, the two biggest probably being paredit (for lisps) and autopair (for everything else).
HTML tag closing (or any other SGML-derived format) is built into html-mode. It’s just “C-c /” (nxml-finish-element).
For jumping around tags, there are a bunch of nxml-* and sgml-* interactive functions. Most of these aren’t bound to keys by default, though, so you’ll have to make up key bindings yourself. I use them internally in Skewer’s HTML mode to compute a CSS selector for the tag currently around the point. It jumps up through tags one at a time, keeping track of what kind of tags are visited until it hits the root.
Just installed closetag and match it. They’ll come in handy when I’m debugging my client’s self-written HTML! Already had autoclose for quite a while; its one of them things you install and then forget about. It just does its single better than IDEs I’ve found – had this annoying problem in eclipse (a short while ago – used to work with some Mr. Donning-Kruegers who said Eclipse was the best thing that happened to them and believed it – till I vimmed) where you’d have do avoid typing in your flow or otherwise, you’d be duplicating closes for things.
Two I would have added to the list personally;
– Neatstatus (the one you wrote actually)
– Fugitive
Neatstatus gives me the info I need when I’m editing stuff so when I’m doing includes or forget what mode I’m in, its perfect. I find it to be very non-intrusive too. It doesn’t give me any problems – just sits there and helps me when I need it.
Fugitive is a git wrapper plugin thingie written by Tim Pope (the pathogen guy) which for its Git Blame inside vim alone makes it a very good addition (although makes me scream at myself quite a bit when I realise I’m the one that screwed something up) besides everything else it can do.
As a Clojure hobbyist, I prefer paredit to autoclose, but I’m not sure if it counts as tiny.
It doesn’t just automatically insert closing brackets, it keeps brackets balanced: you can only delete brackets in pairs, and then only if they’re empty (you can still do d% to delete a pair of brackets AND its contents). You can also do something akin to Emac’s “slurpage” and “barfage” by jumping brackets back and forth over sub-expressions, expanding and shrinking the brackets’ extent.
It also has a neat option whereby closing brackets spread over several lines can be quickly gathered up at the end of one line, in good Lisp style.
It saves a heck of a lot of “unexpected EOF” errors. If you’re going to code Lisp in Vim, I’d argue it’s almost essential.
i tried all three of these and i can’t get matchit to work. it’s clearly loading but even editing a plain vanilla html file it won’t jump between tags using %.
Raimondi/delimitMate is actually much better than autoclose.
autoclose does not work for me when inside html tags:
this is not closed and that is a pitty as in django templates this is all there is :)
thanks for the delimitmate tip, i will surely try it.
i find the snippets feature one of the most useful, although i am not
settled with the plugin itself to do it. ultisnip core dumps my vim..
what is the plugin doing the vertical line thing? :)
grrr, it ate my html tags in the example above..
and it eats it also in between code tags,
a rather unfortunate non-feature of this comment system :(
bbforum syntax to the rescue!
[div]{[/div]
Great advice! Question: In your vim-AutoClose functionality screencast thing, after you create the brackets, the carriage return placed the closing bracket 2 lines down and placed your cursor 1 line down and indented nicely. The parentheses and bracket auto-closing works fine, but when I press Enter from within the bracket pair, the usual thing happens where I simply create a new line with the closing bracket as the first character. Any idea why this wouldn’t work for me? Thanks!
In the first example, to get the closing bracket on the subsequent line, need to set AutoCloseExpandEnterOn. This isn’t documented, I’ve sent the author a patch.
Example in .vimrc:
let g:AutoCloseExpandEnterOn=”([”
I constantly found myself hitting enter twice, then escape, then up one line, then back to insert mode.
A small tweak, but I’m constantly on the lookout to squeeze out more performance.
Ben L, I believe this answers your question as well.
@ Matt Mendell:
Thanks Matt! That works perfectly. Now I can get rid of the CTRL-Space mapping I had set to do that.