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.

Vim-AutoClose Functionality

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:

CloseTag Plugin in Action

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:

Vim-MatchIt in Action

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.

The wise advice that is always thrown around by seasoned vimmers is that you should use it for everything. It doesn’t really make sense to fire up another text editor if you want to write a letter, a blog post or a short story. If it involves editing text, it should be done in Vim. That said, Vim can sometimes be less than perfect for that sort of thing. Or rather, there are more enticing alternatives out there: like Write Room for example.

With the default, out-of-the-box settings Vim can be less than perfect for editing text. For one, it is an editor designed to work with lines of text and when you write code, the last thing you want is for your editor to fuck with your lines. Thus most people opt to have no line wrapping or soft line wrapping by default to avoid headaches. When writing prose, you don’t really work with lines. You work with paragraphs.

What is a paragraph though? Well, in most editors it is a block of text composed out of lines that are wrapped to fit to screen/container width. For Vim however a paragraph is technically just a single line. If you have no wrapping enabled then your paragaph will simply scroll off the screen to the right forever. If you have soft wrap, then it will be nicely wrapped wot window width but still synonymous to line. All line based commands will affect the entire paragraph. So for example, d d can potentially blow away half a page or more, which is not technically what it was designed for.

Hard Wrap is Your Friend

The #1 problem of editing prose with Vim is not as much configuration as the approach people take to it. There is this notion that text files should be soft wrapped because that’s how other editors do it. This is however not necessarily true for all use cases. If you think about it logically, a lot of non-code text files you might be editing with Vim do not necessarily require soft wrapping. Readme files, for example, actually benefit from having lines hard wrapped around the column 80 as most text editors and viewers will open them in a window that is 80 characters wide or wider.

I submit that most of the time when you are writing prose in the form of plain text files, you are actually writing “source code” of sorts. By that I mean that the file you are writing is not the end product, but instead it will be run through some sort of conversion tool (like Pandoc) and end up as a PDF, HTML or maybe a Microsoft Word file later on. This of course means that the way you wrap your lines is inessential, as most tools that generate fancy, rich text out of plain text files are not particularly interested in white space unless it indicates end of paragraph.

This means that you can technically hard-wrap your text without ruining shit for everyone. And as soon as you do, life becomes easier. Scrolling stops being wonky, j and k work properly and all normal mode commands start to work properly.

These are the settings I typically recommend you set up when working with text documents:

setlocal formatoptions=ant
setlocal textwidth=80
setlocal wrapmargin=0

The t option ensures text gets wrapped on textwidth and the a turns on the real-time reformatting as you edit. In essence it means that your paragraphs will get re-wrapped automatically each time you insert or delete characters. It feels exactly as working in soft-wrap mode.

Typically when you open a new file that was soft-wrapped you may want to re-format it using the good old g g g q G sequence. Quick word of advice – it is usually a good idea to disable auto-indentation before you do this, since it sometimes will indent paragraphs in a weird way if you forget:

setlocal noautoindent
setlocal nocindent
setlocal nosmartindent
setlocal indentexpr=

Please note that hard-wrapping your text is mostly reversible. In most cases you can reset your file back to normal using two commands:

:set formatoptions=croql
:%norm vipJ

In case you are not fluent in Vim, the v i p key combo stands for “visual internal paragraph” – in other words, it selects current paragraph in visual mode. The J command “joins” lines. The command above simply runs this across the entire file, re-flowing every single paragraph.

This method is not perfect though, as sometimes short (one or two line) paragraphs get “swallowed” by their neighbors and I haven’t really figured out why that happens yet. It might actually be something unique to my setup.

Aesthetics

The other problem a lot of people have with Vim is that while it works well for code, it is not as aesthetically pleasing or fun to write in as some of the distraction free editors, or just about any plain text tool that was created for writing prose. I find this to be mostly a configuration issue. For example, when I write prose, my Vim looks more or less like this:

Vim in Prose Writing Mode

You note that it has wide margins on each side, the font size is slightly bigger than my code writing font and the line numbers are turned off because I find that I don’t actually need them as much. They tend to be incredibly useful when refactoring code or debugging but when writing prose I typically never actually need to edit more than the current line, and the lines directly above or below it.

How did I get the margins to work like that? Like this:

set foldcolumn=10
set columns=100

As you might remember, I set my textwidth to 80 characters and I have auto-wrapping on which means my text will never be wider than that. I set my window width to be exactly 100 columns which is how I get the right margin. The left margin is a little bit more tricky – to get it I’m abusing Vim’s folding engine by setting the foldcolumn value to 10 columns. This works well, because I don’t use any folds when I write prose and so I can abuse that feature to create margins to my heart’s content.

This is not necessarily as good as distraction-free full screen mode, but it works well enough for me.

To make switching to “prose” mode semi-automatic and easy, I wrapped all of the above into a function that toggles it on or off. As I’m still tweaking it and trying new things, I haven’t made it into a real stand-alone plugin yet (though that may happen at some point) but it is included along with my Vim files and accessible here.

Why not VimRoom?

I’m aware of VimRoom but it didn’t really work for me. For one, I find it a little bit invasive: it works by opening bunch of buffers, then hiding stuff by altering your color scheme. It doesn’t work nicely with vim-obviousmode and vim-neatstatus which I kinda like having around. Not to mention the fact that it doesn’t automatically detect and use your current color scheme. As you can probably see from my screenshots I use Solarized Light, and VimRoom defaults to a rather odd dark color scheme that is not even close to Solarized. Enablign it makes my editor window look weird – mostly black with patches of Solarized yellow and odd blotches of color where it attempts to hide stuff. To make it work you essentially have to feed it the solarized color-codes for just about everything by hand.

So I opted for something much simpler and much less finicky and prone to breaking all the time.

How About You?

This is how I solved the problem of writing prose in vim. How do you do it? How about Emacs users? Is your editor perfectly fit for writing blog posts and short stories out of the box, or do you need to tweak it a bit to work better? Share your tips and tricks in the comments. Maybe we can learn from each-other.

The side effect of such a fishing expedition is that you sometimes find blog posts that are exactly up your alley, but which tackle the subject so well that they leave precious little for you to add to. So then you are left with a choice of either linking to said block and saying “I agree with what that guy said” or blatantly plagiarizing it and hoping no one finds out. The other day I stumbled onto just that kind of article: one that I would love to have written.

The funny thing is that a lot of the ideas in that post were sort of in the back of my mind lately. I have been doing a lot of thinking about code readability, formatting rules and style guidelines for a lot of languages. I have been doing a lot of jumping around between PHP, Python and Ruby lately and I’ve been noticing how each of these languages approaches code style. Python for example strictly enforces proper indentation by making it part of the language syntax, coercing you to write code certain way. This of course doesn’t mean you can’t write atrocious python code, but it is generally harder to do than with say PHP.

The way code is presented definitely impacts it’s readability. I’m not just talking about the usual code guidelines such as using descriptive variable names and structuring your code the right way. I’m talking about purely aesthetic properties of code: consistent indentation style, short line length, alignment of elements in declarative blocks and etc.. go a long way in making the code easier to digest understand. This is the gist of the argument put forth in Dave Copeland’s recent Source Code Typography post: the way you indent and align your code matters.

For the lazy, let me re-use one of his examples: a snippet of a pretty common code you could find in a Ruby on Rails application:

def text_field_tag(name, value = nil, options = {})
  tag :input, { :type => "text", :name => name, :id => sanitize_to_id(name), :value => value }.update(options.stringify_keys)
end

This is fairly concise, albeit ugly code that scrolls off the page in most editors. Unless you have a decent sized screen you can’t actually look at the whole line without scrolling – and even then the length of it makes it impossible to figure out what is going on here at a glance. Dave argues that a very simple re-formatting can drastically increase the readability of the above code:

def text_field_tag(name, value = nil, options = {})
  tag :input,
      {
           :type  => "text",
           :name  => name,
           :id    => sanitize_to_id(name),
           :value => value

      }.update(options.stringify_keys)
end

I’m not going to re-iterate the entire post here – I recommend you just go and read it yourself. Dave makes some excellent points, especially with regards to the annoying leading comma convention that has become fashionable in the JavaScript community lately. What I want to do is add to his article by pointing out that there are tools you can use to make formatting code easier.

For example, to keep your code lines relatively short it is a good idea to set up your editor or IDE to highlight column 80 giving you a visual indication as to how wide your code ought to be. This provides a soft boundary that you can go over if needed. In Vim this can be done via a single line added to your .vimrc:

hilight ColorColumn guibg=lightyellow ctermbg=227

You can of course substitute lightyellow and 227 to your choice of colors – I picked these because light yellow goes well with my Solarized Light theme: it is visible, distinct but not too jarring:

Column 80 Highlighted

Similarly, when you need to re-align some code (as in the example above) there exist two plugins that will do the job for you: Vim-Align and Vim-Tabular. The later is the newer, more feature rich plugin and there is an excellent Vimcast on it that you can watch here. Both essentially help you align blocks of code based on some sort of a token. They make a task that can be quite labor intensive (a lot of moving around and tabbing) into a two step process: select block to be aligned, then issue the alignment command such as:

" tabular.vim
:Tab /=>

" align.vim
:Align =>

In both cases alignment is usually done while respecting your tabs/spaces settings ensuring that things don’t completely break apart next time you re-tab your file (using g g = G).

How do you ensure that your code is optimized of maximum readability? Do you have any plugins or tricks for your favorite text editor you would like to share? Let us know in the comments.

To be honest, I was never that fond of that particular extension for a variety of reasons. One of my chief gripes with it is directly related to the way it looks. Powerline uses non-standard patched fonts in order to achieve that segmented look which is not something Vim supports natively. Without them the extension looses a lot if it’s sex-appeal and starts looking a bit plain. To configure it, you don’t just add entries to your .vimrc but instead you need to create a separate dot-folder where it’s settings files are kept. While this neatly separates the Powerline setup from general Vim settings it also adds maintenance headaches. I like to keep all my Vim related config files in a single directory under source control so you can imagine this is less than optimal.

Finally, I have never really felt like I would use any of it’s advanced features. Most of the power-line setups I see on screenshots and in screen-casts are very basic: mode indcation, file path, some file and cursor position info. All of that can be easily set up in just a few lines of VimL. Powerline on the other hand is a monstrous semi-framework that can let you do really frivolous and complex things. For example, it has support for hooking into your power management module by the way of python and displaying battery status in Vim. It can also pull weather notifications from the web and display them in your status line… Though why would you ever want that is beyond me.

It is really a nice an powerful plugin, but it doesn’t seem like something I would necessarily need. For years I have been pretty happy using a very simple status line with just the name of the file and some positioning info along side the excellent Obvious-Mode plugin. It covered most of my needs – my status line would be red in insert mode, gray/cyan in normal mode, depending on whether or not the file had any unsaved changes.

Lately however I decided that I could use more informative status line. I briefly flirted with the concept of using Powerline but since I’m a system nomad who drags his .vim folder wherever he goes that idea died pretty quickly. Instead I decided to create my own status line which displays the information that I care about in a Powerline-like way but without any fancy fonts.

The killer feature for me is that I wrote it. By that I mean that if something breaks or doesn’t work correctly can easily figure out why, and fix it. Power line is pretty big and has a lot of moving parts, whereas my status line is just a dozen lines of very basic VimL so if it breaks, I can easily handle it without loosing too much time.

The result looks like this:

Vim-NeatStatus Plugin

The mode indicator on the left changes color depending on the mode: green in normal, red in insert and blue in replace mode. I also had it turn purple in visual mode but it was kinda buggy (always lagged one keystroke behind) so at the moment it doesn’t do that. I still use Obvious-Mode so this functionality isn’t strictly necessary, but I included it so that it could be used as a stand-alone plugin.

The black box next to mode indicator shows you the server name (which in my case is treated as session name). This may not be useful to everyone, but since I set up my Vim to save sessions on exit I actually like to see that information somewhere.

To the left of the file path I have file type (ie. what language vim thinks this file is written in), file format (important if you jump between systems as much as me) and encoding (as in utf8 or not). The last may not seem fairly relevant to you, but sometimes it does matter: especially if you are trying to parse files in a certain way, or if you create a script that doesn’t run properly because the non-vim text editor decided to insert a BOM in it for shits and giggles.

Next I have the buffer number (which is useful when you have a lot of buffers open) and cursor positioning info with the current line highlighted in pink to stand out and be easily readable. There is also one more bit that is not visible in the picture above: whenever you edit a file, a little pink notification appears in the right corner of your status bar to let you know that the file has unsaved changes. Once again this is a duplication of Obvious-Mode functionality but it can be useful if you decide to install it as a stand-alone.

The colors work both in the graphical Vim as well as in the console (though you may need one that supports 256 colors). I tested it in in Gvim, MacVim and using Gnome-Console as well as Cygwin MinTTY on Windows.

I made the entire thing available as a plugin that can be easily installed via Pathogen like this:

cd ~/.vim/bundle
git clone git://github.com/maciakl/vim-neatstatus.git

If you have your .vim under source control like me then do:

cd ~/.vim
git submodule add git://github.com/maciakl/vim-neatstatus.git bundle/vim-neatstatus
git submodule init
git submodule update

At the moment the colors are hard coded and the plugin is not very configurable as a whole, but that will likely change in the future. If something is broken or the colors look atrocious under some setups let me know and I will try fixing it.

Are you able to change the status line in your favorite text editor? If yes, what kind of information do you put there? Have you written your own status line or are you using a plugin written by someone else?

Vim and Emacs users are different – take one at random from each camp, put them in a room and sooner or later you will find them talking about that plugin/extension they wrote for their editor. Why is it that majority of people who use these two tools always eventually end up writing custom plugins for their editor, whereas most other programers never do? Perhaps Vim and Emacs simply attract certain kind of minds to them – inquisitive tinkerers and hackers who simply like to tweak and customize things. Or perhaps it is that both these editors are just so easy to tweak and modify that there is simply no barrier to entry. If you have written your .vimrc from scratch (as every Vim user should – don’t let anyone tell you otherwise) then you already know how to write plugins. In fact, you have probably already written a few without realizing it – all you would need to do now would be to dis-entangle them from your config file and generalize them a wee bit so they can be installed as a self contained module. Same goes for Emacs.

Of course, whenever Emacs user and Vim user start talking about plugin developments, the former is bound by law to smugly condescend about the quality of the respective domain specific languages employed by each editor. Emacs uses Elisp which is a Lisp flavor and therefore superior.

You see, the ancient legend says that before the universe was compiled, the creator deity pondered for a spell, and then on the first day said Let there be parentheses! and he saw they were good. Then on the second day he said Let code be data and data be code and there was much rejoicing. Then on the third day he hacked up a meta-programming macro, and fucked off for the rest of the week as the universe generated itself. Then, millions of years later man invented haskell and was like “What now god?” and god was like “Shiiiiieeet, son!” because in his omnipotence he saw it was also pretty fucking awesome, though mostly in an incomparable to lisp in an apples to barnacles kind of way.

The point is, Emacs users have a pretty cool language they can play around with. Us Vim users, on the other hand, have VimL which is… Neither pretty nor elegant. It has no OOP support, weird scoping, too many overloaded syntax level operators that behave differently based on context, no JIT, and it allows (or even encourages) you to write terrible, unreadable spaghetti code that is worse in terms of readability than Perl. You could probably argue about Elisp’s aesthetic flavor with all the parentheses and what not, but at the end of the day it is rather elegant and consistent environment. VimL is quite the opposite: it is quirky, inconsistent mess of a language that grew along with the editor developing strange warts and tentacles along the way. It is much like a giraffe developed by a committee: while it is supposed to be a giraffe, it is actually an aardvark wearing a pineapple fruit hat and a monocle. It is neither glamorous, nor particularly fun to work with – but it will get the job done if you clench your teeth and try to resist the overwhelming urge to slap it in the face for being so goofy looking.

Fortunately for us, we have options. Modern versions of Vim tend to come pre-baked with support for alternate languages such as Python or Ruby for example. So if we wish, we can get away from VimL and write code that looks and reads nicely. Of course such a thing comes at a trade-off. The general rule of plugin development is that the further you go from the native language the editor “speaks” the worse off you are. In case of Emacs, this doesn’t matter because it was largely written in Elisp (except the few small parts that were coded in C). Vim is mostly implemented in C with VimL already being second class DSL so putting another layer of abstraction between us and the editor can become problematic. So the rule of thumb is that for simple stuff you should stick to VimL and fall back on external language only when you have to do some heavy and/or convoluted processing. VimL is closely tied to Vim but not as expressive as it could be when it comes to representing complex program logic.

Python, on the other hand is. While, perhaps not as elegant as Lisp, Python is nice, strong, opinionated and beautiful language. Opinionated, because among other things, it doesn’t give a shit about your preconceived notions regarding the use of white space. Beautiful, because it is the kind of language that will force you to write code that doesn’t look like shit or die trying. It is the language you need, but perhaps not one you deserve.

Also, because it is older and more mature than Ruby and therefore you have a better chance of it being compiled in your copy of Vim. Mature only in software terms of course – after all making Monty Python references in your code is the accepted development pattern and recommended best practice after all.

How do you know if your Vim can handle Python code? Well, it is easy:

• If you are outside of Vim you just run vim –version and look for +python which indicates you’ve got it or -python which indicates that whomever compiled your vim package is a major douchenozzle.

• If you are inside of Vim you can just issue the :py 1 command. If nothing happens, you are good. If you get an error message complaining that py is not an editor command, then… Douchenozzle.

Once you have confirmed that your vim will consume python code, you go about writing a plugin as you would with a VimL one. First, you create a file: say helloworld.vim or something like that. Then, at the top of that file you place some contingency management code:

if !has('python')
	finish
endif

This checks if the user’s editor has the Python support baked in, and silently quits if it does not. This is a nice thing to do, since it prevents someone’s editor from blowing up. Chances are the person who will be installing your plugin doe not read your README file and thus does not realize he needs python support, and therefore his Vim will blow up with a barrage of error messages next time he launches it.

Of course we could try being more explicit, and display an error message along the lines of “Y U has no +python!??” but I personally prefer the silent failure. Don’t get me wrong, explicit is almost always good, but I hate when plugins spam me with error messages on start-up. I keep my .vim/ directory under source control and I clone it onto every machine I work on. Sometimes I don’t have the luxury of using the latest and greatest Vim with all the fancy options. I don’t like to build specialized configs for those special cases – I’d rather use my usual setup, and just have the fancier stuff fail silently and simply be unavailable, rather than vomit stream of warning messages at me every time I do something. But that’s just me.

Next we want to expose some interface to the user in VimL so they can, for example bind it to a command or a key. That part has to be done in VimL. Think of it as bridging the divide between the native language and the external one. Usually, the best way to expose some functionality to the user in an unobtrusive way is to create a publicly accessible function:

function! HeloWorld()

endfunc

In general, you can access the Python environment in Vim by issuing the :python command (short version :py). You could technically write an entire plugin by simply prefacing every line with that command, but that would be extremely ugly and kinda crazy. Instead we can do something like this:

function! HeloWorld()

python <<< EOF

print "Hello World!"

EOF
endfunc

Now you can do :source % to load it up, and call HelloWorld() to test it. If all went well, you should see the text Hello World in the status line.

Granted, this is still kinda ugly. Mixing VimL and Python in a single file is definitely non-kosher, and it completely defeats the purpose of this entire exercise: to write plugins in a more elegant language, and make them more readable. Fortunately, there is another command we can use to load up an external python file, and execute it in Vim context: :pyfile (or :pyf). So our ugly function can be reduced to something like:

function! HeloWorld()
    pyfile helloworld.py
endfunc

"That is all well and good," I can hear you say "but what does this do for us?" To actually do anything interesting as a plugin, your Python code needs access to internal Vim stuff - like the buffer list, or the contents of said buffers. How do we get that?

Well, we get it via the magical vim module. It is magical because it isn't really a module that you can go and download or install in the usual way. It doesn't exist on the outside, and can only be imported when the script is called from within Vim. This is both good and bad. It is good, because it makes it completely plug-and-play. If you have Vim with +python there is nothing else you need to do: it just works. On the other hand, it is bad because it requires Vim to work. This means you can't run your code outside the context of your editor. For example, you may not be able use your favorite Python unit-testing suite to run test on your plugin, unless you mock up the Vim module functionality first. Which in retrospect is what you probably ought to do anyway so I guess it works out.

The vim module exposes bunch of useful objects such as vim.buffers or vim.current.buffer that you can use to manipulate your buffers, files and settings. The current buffer for example is actually a zero indexed array, each element representing a line as a string. Any changes to the elements in said array are immediately reflected on the screen. I will let that sit with you, so you can just imagine the possibilities for fun and abuse here.

If you want to know all the available objects and their details, I suggest you RTFM. Just as an exercise however, lets write a quick and dirty python plugin together.

I work with Markdown files a lot, so I always run them through something like Pandoc to check how will they look in HTML format. Let's say I wanted to create a plugin that takes current buffer and dumps it into HTML format without the need for Pandoc or any other converter to be installed on the system. Because I'm lazy and I don't feel like writing actual Markdown converter myself I will just use this Markdown package.

So, first let's create a VimL plugin file that will load our Python code and call it, say markdown2html.vim:

if !has('python')
	finish
endif

function! Markdown2HTML()
	pyfile markdown2html.py
endfunc

command! MKD2HTML call Markdown2HTML()

The last line actually binds my function call to a Vim command providing an easy way for the user to run it. Next let's write our python code:

try:
    import markdown
    import vim
    import string

    html = string.join(vim.current.buffer, "\n")
    html = markdown.markdown(html, output_format='html5')

    filename = vim.current.buffer.name+".html"

    f = open(filename, 'w')
    f.write(html)
    f.close()

    print "HTML output written to "+filename

except ImportError, e:
    print "Markdown package not installed, please run: pip install markdown"

Bam! Instant plugin. How awesome is that?

Of course the downside of using Python to write your plugins is that the users will need to have their editor compiled with +python in order to use them. Also, every time you use a third party Python package (like I just did above) your users will need to actually install that package on the system. So if you actually try to implement the above, don't forget to pip install markdown at some point beforehand.

Still, the ability to bring the power of Python and all of it's packages and modules into your Vim plugins is not something one should scoff at. If you would like to see a real life example of an excellent and popular plugin written in Python, go check out Gundo. It's actually a plugin I use all the time as I work.

Vim novices usually come with these preconceived notion of how the tab metaphor ought to work in a text editing context, and become confused when Vim refuses to play by these rules. To put it simply, tabs in Vim are different. They won’t work the way you expect them to, because they were not designed for that. The one file per tab convention is not the Vim way.

Let me preempt the obligatory self-professed “usability expert” snark comments about vim breaking established UI conventions: please kindly go fuck a hedgehog. Bill Joy was establishing his own conventions when he wrote vi while doing your mom long before she spawned you and then became so fat she developed her own event horizon. Complaining that Vim doesn’t implement tabs the same exact way Sublime Text does makes very little sense when you consider the huge architectural differences between these two editors.

The original vi editor, and earlier versions of Vim did not really support tabbed interface. They did however support editing multiple files with a single instance of the program using buffers. If you have ever progamatically manipulated text in some way, you should be familiar with the concept of a buffer. To put it plainly a buffer is the copy of your document that is held in memory as you manipulate it. When you open a file, you load it into a memory buffer, and that’s where your changes are applied as you work on it. When you start a new document, your text is held in a memory buffer until you decide to write it to disk. Vim maintains a list of buffers that it has currently open, and you can view it by issuing the :buffers command (or alternatively the shorter :ls command alias).

You can typically only edit a single buffer at a time, so the current (or active) buffer is the one displayed on your screen, while all the other buffers are hidden away. When you open a new file, a new buffer is created and immediately displayed. The buffer that was being shown before it is not gone, but simply hidden away. Buffers are “like” tabs in modern editors, only they don’t have a graphical UI representation. They work the same though – you activate one of them, and it’s contents become visible while all the other ones are hidden away.

Vim Buffers

You can load any open buffer into your view-port by issuing the :b command followed by a number or partial file name which can be tab completed. The term “view-port” is a key concept here because it helps you understand what is really going on. It is best to think of the display area as a virtual port-hole through which you cane interact with your buffers one at a time.

When you create a split (for example using the :vsplit command) you effectively create two (or more) independent view-ports. Each one has access to Vim’s internal buffer list. So now you can have multiple buffers on the screen at the same time. Or you can load the same buffer in two splits, and watch changes you make on one side be automatically reflected on the other if that’s what floats your boat.

In essence, buffers do everything the tabs in say Sublime Text or whichever other Notepad replacement editor you happen to fancy. They just don’t have the clickable UI warts you might be tempted to fondle with your mouse. Lets face it – using a mouse to operate Vim is kinda like trying to eat tomato soup with a crossbow: it can probably be done, but it doesn’t seem at all practical. In fact, Vim’s buffer list is more flexible than most tabbed interfaces. For example, have you ever tried recursively loading your entire project tree into your editor? Let’s say you have 600 odd source files: what happens if you try to load all of them into your editor of choice? Firstly, chances are your app will crash and burn trying to prerender all these files or hitting some internal memory limits. It will also likely slow down to a crawl trying to create and display tabs in rapid succession (likely refreshing the screen for each one in the sequence). Assuming none of that will happen, your tab bar will likely become completely unusable: tabs will likely be about 1 pixel wide, or will force you to scroll around to find what you need.

Vim on the other hand will slurp up the entire project into buffers without even breaking a sweat because it doesn’t really have to render them unless you actually bring them into focus. Navigating a huge buffer list is actually easier than messing around with hundreds of tabs because you can use tab completion to match partial file names and get to where you need to go very quickly. Vim will also allow you to do bulk-edits using the :buffdo command which lets you run arbitrary vim commands (be it normal mode actions, build-in commands or function calls) on all the open buffers.

So the question is: could we simply force Vim to treat each buffer as a tab for the sake of following the UI convention followed by most of the relatively immature and untested (as compared to vim) editors on the market? The answer is no, we couldn’t. Why? Not because snobbery or entrenched traditionalism. It wouldn’t work because it would break the split screen functionality which is an established feature that predates the tabbed interface by a few decades.

Right now Vim lets you keep splitting your screen into independent view-ports, each of which can operate on a different buffer. How do you reconcile that with tabbed interface? Let’s say you have 7 files open, and you load 4 of them into 2×2 split (split horizontally, then split each half again vertically): what happens to the tabs that were loaded into splits of another tab? Do they disappear from the tab bar? What if you want to swap the contents of the splits? Do you re-shuffle the tab bar every time you split? If no, how do you deal with the tabs that are loaded in other tabs? If yes, how do you prevent tabs from moving around or getting lost? It seems like a very, very difficult problem to solve without altering existing functionality, with little to no benefit for existing users.

Tabs as implemented by Sublime Text and others simply make no sense in Vim world. Which brings us back to the original point of this post: what the fuck does Vim use the tabs for then? I can answer that with an example:

Imagine you are working on some code and you somehow ended up with a 2×2 split as above with 4 buffers on the screen at the same time. Suddenly you realize you need to open another file to tweak a thing or two related to your current task. You don’t want to split your screens any further, but at the same time you don’t want to blow that layout away since you are not done with it. To make matters worse said file is big, complex and ugly, so it ought to be viewed in full screen. In the olden days you would probably suspend (or minimize) your current session, and open another Vim instance to do so. But with tabs you don’t have to. You just open a new tab, which gives you a fresh view-port. One with access to the same buffer list, the same registers and recorded macros. One which you can split into multiple panes if you wish.

Vim Tabs

Vim tabs are essentially work-spaces or view-ports. They are more or less the virtual desktops for your text editor. They are not meant to be bound to buffers, but instead provide you with additional work surface where you can “spread out” the buffers you have opened.

You can of course try to force Vim to follow the “one-buffer-per-tab” convention, but it will always be an uphill battle. I’ve seen people write elaborate VimL scripts to accomplish this. I have seen countless plugins that claim they offer this functionality. But most of them break into thousand pieces as soon as you try to do something fancy with splits, hidden buffers or the :buffdo and :argdo commands. And if you are never going to try anything fancy, complex or weird then what’s the point of using Vim anyway?

From there It is quite easy to fall into a trap of running multiple instances of gvim side by side. While being able to look at two files at once is great, the best way to accomplish this with Vim are splits not multiple windows. Why? Well, when you open a new Gvim instance (ether via GUI or by running gvim from the command line it opens up as a separate process. It doesn’t share the environment of your existing vim instance. What does that mean? It means it can’t access the buffers you have open in the other window, which might actually be what you want. It also isn’t affected by any run-time customizations. It’s argument list, search path and work directory are initialized separately and do not interfere with each other. There are times when this is precisely what you want.

Chances are however that you are working on a few files that are part of the same project and thus you would probably want your Gvim instances to be able to interact. For example you might define a macro in one file, and wish to run it on the other – but you can’t. Hell, you can’t even directly yank and paste between the two windows because they have separate sets of registers. The only way to copy text from one window to the other is by way of the system clipboard, which only works if your version was compiled with support for it.

But what to do if you are a shell fiend, and basically just want to open your files from Bash? Well, you just need to learn one command line switch then:

gvim --remote-silent filename

This will find a running instance of gvim and attach a new buffer to it. From there you can put them side by side using :vsplit (to create a vertical split) and Ctrl–^ to toggle current split pane to the previous buffer and hide the split with :only when you no longer need it. The only thing you have to remember is that you don’t want to use the :q command because it will close the entire application. When you are done with a buffer you save it and then do :bd which in my mind stands for “Be Done!”. There is also the “Be Well!” command :bw which saves the buffer before closing.

Splits and buffers are really the way to go. Throw in tabs for a good measure and you can set up multiple sets of different split panes and flip between them without ever having to take your hands off the home row. But alas, even with cute mnemonics for the buffer closing commands accidents happen. I can’t tell you how many times I had a dozen files open in a single vim session, and in the middle of coding, out of pure habit I typed :wq. Suddenly, all the buffers are gone. All the splits forgotten. All the tabs purged. No data was lost in the process of course, since the files themselves were saved. The undo history was preserved as well because I use Vim 7.3 and enable the persistent undo feature. But the contents of the registers and the buffer list was blown away.

This used to happen to me at least once per day, until I set up automatic session saving for myself. Vim, as any good editor as a session feature. When you issue :mksession command it will save the list of open buffer and tabs as well as your register contents into a file called Session.vim in the current working directory. You can then run gvim -S and it will look for a session file in the current directory and restore from it. Alternatively you can :source that file.

Unfortunately this does not help you with accidental closing of vim, as you need to remember to save the session yourself. Of course you could always add this to your .vimrc:

autocmd VimLeave * :mksession!

This will automatically save a session file each time you close your editor, which is much better. Unfortunately this will quickly litter your filesystem with session files. It is about as annoying as those damn .swp files vim loves to produce by default. I have disabled those long time ago because I have never actually had to use one and decided they were not worth the hassle. Session files in every directory bring back these bad memories. Fortunately you can redirect your session file to somewhere else, like:

autocmd VimLeave * :mksession! $HOME."/.vimsessions/session.vim"

Now however you have only one session file, which gets overwritten every time the editor closes. This works when you accidentally blow away your buffer history like in the example above. But let’s say you are done for the night, and you close vim confident your session is saved. Then you run git commit to commit your changes into the repository. Git of course helpfully launches Vim to edit your commit log, and then happily overwrites your session. Next morning you want to get back to work, and your editor opens with a stale commit log message rather than a screen-full of buffers. Less than optimal, don’t you think?

I’ve been trying to figure out a good way to manage my sessions and eventually got an idea of naming my sessions. You can name your vim instance using the –servername command line switch like this:

gvim --servername dev

You can grab that name inside Vim using the v:servername variable, and use it as a unique name given to your session. Whenever you work on a specific project you launch it with a relevant servername and that session will be preserved. If you later run Gvim without that switch, it defaults to GVIM or an empty string if you ran the console version. This means that editing a commit log won’t accidentally blow away your session.

Here is how I’ve done it:

" where do you want to save sessions?
let g:session_dir = $HOME."/.vimsessions"

" Save sessions whenever vim closes
autocmd VimLeave * call SaveSession()

" Saves the session to session dir. Creates session dir if it doesn't
" yet exist. Sessions are named after servername paameter
function! SaveSession()

    " get the server (session) name
    let s = v:servername
    
    " create session dir if needed
    if !isdirectory(g:session_dir)
    	call mkdir(g:session_dir, "p")
    endif

    " save session using the server name
    execute "mksession! ".g:session_dir."/".s.".session.vim"
endfunc

That’s only part of the equation. Once you have sessions that save automatically, you also want an easy way to restore them. So I made another function that runs when you open vim:

" Load session when vim is opened
autocmd VimEnter * nested call OpenSession()

" Open a saved session if there were no file-names passed as arguments
" The session opened is based on servername (session name). If there
" is no session for this server, none will be opened
function! OpenSession()

    " check if file names were passed as arguments
    if argc() == 0

    	let sn = v:servername
    	let file = g:session_dir."/".sn.".session.vim"

        " if session file exists, load it
    	if filereadable(file)
            execute "source ".file
        endif
    endif
endfunc

One thing I decided here was that if I was opening a file in Vim, chances are I wasn’t interested in restoring the session. Most of the time when I run Gvim from the command line with a file argument I just want to quickly edit said file and be done with it. So I opted to never bother restoring sessions if a file argument was present.

If vim is opened without specifying a file, then I try to find a session file based on the servername variable. To make this even more seamless I actually added a few aliases to my .bashrc:

alias gv="gvim --servername DEV"
alias g="gvim --servername DEV --remote-silent"
alias gv="gvim --remote-silent"

So when I sit down to work I run gd on its own and it creates a named DEV session for me. Then I use g followed by filename to attach new buffers to it as needed needed. If I ever have to open an unrelated file, I use plain old gvim command which opens up a completely independent instance which doesn’t touch my session data. If I want to attach buffers to that session I can do that with gv. It works quite well, and it also reduces the amount of typing that I need to do at the console – so it’s a win-win in my book.

As a rule, I tend to use the dark Solarized theme for my terminals, and the light one for my Vim. Why? I don’t know. I prefer to edit text with dark text on a light background, but dark on light terminals look weird to me. Plus, the stark contrast between backgrounds makes it easy to distinguish an editor pane from a shell pane in Tmux.

Sadly, depending on your system, half the time you open Vim inside of Tmux, Solarized theme (both light and dark) look like shit. This only happens when running the console version of vim from inside Tmux. I hardly ever have issues with the Solarized theme in the command line vim when running it directly. But when it is launched from inside of Tmux, the color scheme is off and moving the cursor introduces strange artifacts on the screen.

Why does that happen? I’m not entirely sure. It appears that Tmux happens to be very finicky about terminal types, and tends to default to 16 color mode rather than the 256 color one required to use Solarized themes. Fortunately, you can usually force it to behave properly by following these steps:

First, set your terminal (Konsole, iTerm2, Putty) to identify as:

screen-256color

Why screen? Because Tmux is a screen-like program, but it likes to inherit the terminal type from the terminal that launched it. You could also use xterm-256color but in my testing setting it to screen worked every time, while xterm setting was problematic under some combinations of terminals and shells.

Next, add these two lines to your .bashrc:

export TERM="screen-256color"
alias tmux="tmux -2"

Again, we are once again telling Tmux the terminal type is screen-256color regardless of what the Terminal says. The $TERM environmental variable is the second place where Tmux likes to inherit it’s terminal type from, and if you have a miss-match between the value declared by your actual terminal, and by your shell then Tmux gets confused. The second line forces Tmux to always start in 256 color support mode.

In your .tmux.conf add this line:

set -g default-terminal "screen-256color"

As you can see we are covering all the bases. The point is to give Tmux no choice but to use screen-256color terminal type, regardless of what it might want to do.

Finally, in your .vimrc add these two lines:

set t_Co=256                        " force vim to use 256 colors
let g:solarized_termcolors=256      " use solarized 256 fallback

Once you do all of this, the Solarized theme should work from within Tmux. I have tested this setup on Kubuntu with Kterm as well as on Windows with Putty and it worked in both. If you know of a better way of ensuring that Vim + Solarized work with Tmux, please let me know in the comments.

I’m not talking about standard shell tools that are part of the coreutils pacage on most systems – we all love things like ls, grep or wget but these things are usually always there. I want to know what are your top three indispensable things that may or may not always be there on a stripped down fresh install.

Here are mine:

Vim 7.3

You would be hard pressed to find a Unix or unix-derivative system that does not ship out of the box with a copy of vi. Most linux distros actually ship vim and simply alias it to vi in compatible mode. But, Vim 7.3 is still pretty hard to come by. Unless you are rolling out brand spanking new fresh release, chances are you will have version 7.2 on your system.

Why do I prefer 7.3? Well, it has a handful of features that I grown to like and rely on:

1. Persistent Undo is huge help. Unlike most editors, Vim 7.3 will preserve your undo history even after you save and close the file. This is like having a poor-man’s version control for your files, without actually using version control.

   Unlike most text editors who track edits in a linear way, Vim keeps the undo history as a tree data structure which you can traverse back and forward without actually losing any work. There exist plug-ins such as Gundo which help you visualize and browse your past edit branches with ease.

   As you can imagine, once you get used to undo history persisting after file is saved and closed, it is hard to wean yourself off of it. It is just too useful and convenient of a feature not to take advantage off of it.

2. Relative Line Numbers – 7.3 has this nifty feature which numbers the lines relative to the cursor position. So the current line you are editing is always line 0, and the numbers grow up and down away from it. Why on earth would you want that? Well, it’s a Vim thing really. Vim commands don’t take absolute line numbers or ranges as arguments – they take offsets. So instead of saying something like “do this on lines 5 through 7” you instead say “apply this to the next three lines”. Which means that seeing at a glance that the end of the code block you want to manipulate is N lines away from your cursor without having to count is extremely beneficial. It makes you more productive.

Could I survive working in 7.2? Yeah, probably – but if I can help it, I install 7.3 just to have an uniform work environment across all the machines I work on.

As to why did I include Vim itself on this list? I believe I already answered this question quite throughly.

Tmux

I found out about tmux only few months ago, but I’m already addicted to it. It is a tool so indispensable to me that I will go to great lengths to compile it from source if it happens to be unavailable on a machine I need to be using. Especially if it is a remote machine.

Tmux is a terminal multiplexer – a drop-in replacement for the venerable screen. If you have never used screen, I am about to rock your world my friend. This is the tool that will revolutionize how you work on the command line.

Here is how I explain this tool to complete n00bs: you know how vim and emacs have buffers that you can toggle between or even put side by side in split-screen mode? Terminal multiplexers give you exactly that – but for your shell.

Let me give you a hypothetical example: let’s say you ssh to a server and you are editing some config file. You need to change some value, but you don’t remember what are the allowed values and ranges for that setting. What do you do? Well, you could Ctrl+Z out of your editor, check the man page, and fg back… Or you could grab the mouse, and look the value up online, or locally.

Or you could split the screen, and open the man page side by side with the text editor like this:

Using Tmux on a remote server

Here you see me editing .tmux.conf viewing the man page, and keeping my eye on how hard PogoPlug is working by running top. All on one screen via single PuTTY SSH session from windows. And if I accidentally close my PuTTY window, all I need to do is to ssh back into the box, and issue a single command:

tmux attach -t session_name

All the stuff that I had open doesn’t close when my connection is lost, but keeps on chugging. This is great for big compile jobs – you just type in make, log off and go eat your dinner while the code compiles in the background.

Why Tmux and not Screen? Because it is easier to use. The key bindings are easier to configure, the screen splits look aesthetically nicer. And of course it is just much more friendly to use. For example, in Tmux opening a new shell instance in a vertical split screen buffer is a single action, whereas with screen it is usually two (first you split the screen, then you create a shell session in the new buffer).

Git

Without git I can’t get anything done. For one, I keep a lot of my config files under source control. When I set up a new machine, I usually immediately instal git, so that I can clone my .bashrc, .tmux.conf and .vim/ files and get my working environment in order. Only after I do all that I can start doing actual work.

Git is useful for more than that though. My personal philosophy is that anything I have spent more than 10-15 minutes creating ought to be under version control of some sort. This is sort of a rule to live by, and every time I bent or violated it I got burned pretty harshly. But do not rely just use it locally – a local git repository can be easily blown away along with your work by an accidental deletion, hard drive failure or a myriad of other accidents. If it’s worth sharing, put it on Github. If it is private, show it away on BitBucket. If you do not ever want it to leave the confines of your LAN, set up bare repository on another machine you own, and push your work there regularly so it is in at least two places (well, four – because you are backing both machines up, right?).

Granted, git is not the only source control system out there but it is one I have become fond of. It runs on just about every platform, and once you grok the basics it is actually fairly straightforward to use – especially for small, single person projects. It has great remote services, and pretty good assortment of client side tools (I hear good things about the Github clients for Mac/Windows and stuff like TortoiseGit).

What are your top 3 tools that you couldn’t live without? Let me know in the comments.

Anyways, I have been doing a lot of writing and thinking about mobile technology. Clearly, portable computing is the future. The age of the desktop already passed, and traditional laptops are currently entering their twilight years. Pretty much everything that is not paper thin, and has a old-school spinning hard drive is to bulky to lug around.

I love my MacBook Pro but whenever I take it out “on the road” I find that it is not as portable as you would expect it to be. After about 4-6 hours of happy mobile computing I always find myself in a desperate need of a power socked to witch I need to tether myself. Compare that to the iPad which has a battery life of more than 10 hours. I charge that thing about once a week, and when I do I can stick the cord into any available USB port. The MBP needs to get plugged into a wall every day.

Clearly one of these devices was designed to be more “portable” than the other. A laptop (not just the MacBook – this goes for all the laptops out there) is more of a portable desk-top machine if think about it. You get to the office, plop it on a desk an start working. Then you fold it up, go home, plop it on another desk and work some more. Despite the name, keeping a laptop on your lap is not the most comfortable way to do computing. I mean, it can be done, but it will fuck up your hands after a while. The keyboards and touch-pads on those machines are not meant to be used from your lap.

A tablet, on the other hand was specifically designed for that type of work. It has the battery life, the form factor and the touch based UI instead of a mouse which prevents you from contorting your hand into a weird, unnatural position to click on things.

So a natural thing to ask is: could you work off your tablet? Could an iPad act as your primary workstation?

For me the answer was always no. An iPad cannot replace my laptop because it cannot run the tools I need to do my job. Even if there exist iPad versions of Vim and Python they do not meaningfully interact. Without file system, a working implementation of Git or the ability to install a web server I would not be able to do my job using it as a primary tool. I could use it as a lightweight email reader, but that’s about it.

For real work, I still need an actual computer. Something running a traditional OS. Something that can at the very least approximate the destination production environment towards which I’m developing.

But… Does this “actual computer” need to run on the machine I carry with me? Could an iPod be used as a thin client that connects to a remote system that lives somewhere else? Like at work? Or at my house? Or in the cloud?

Well… I don’t see why not. In fact, I’m not even sure why I haven’t done this already.

About a year ago a guy named Mark O’Connor has swapped his MacBook for an iPad and Linode. I highly recommend you read that article, because it is both inspiring and fascinating. Much like me, Mark is a user of Vim, and a person who is quite comfortable living on the command line. People like us run graphical environments mostly for stuff like Web and Email (because browsing the web in a text browser really sucks). We both chose MacBooks mostly because they had a fully functional Unix shell in a nice, hassle free UI package that surrounds it. Our real work happens on the terminal, and the other stuff (email, web, etc…) happens outside of it. They are basically expensive hardware and software shells that surround our primary work environment. But there is no reason why we would need to run said environment locally. There is no reason for the CPU that compiles and runs my code to be in the same physical location as me. As long as I can see the output, and there is no input lag, I don’t care where does that CPU live.

Mark has been using his iPad+Linode combo for close to a year now, and he reports no significant issues with the setup. At first he treated the whole thing as an experiment, but now it has become a way of life. Apparently the 3G connection by the way of a tethered iPhone is fast enough to run iSSH reliably and without much lag or hiccups. That said, he does live in a country with pretty decent cellular coverage. We Americans have to struggle with cell networks that barely approximate third world coverage. Still, this is quite impressive.

If you are curious about Mark’s setup, he described his entire stack and configuration here. For what it’s worth, I would use Tmux instead of Screen, would not need VNC access and of course use my own .vimrc. Other than that seems like a pretty decent set of suggestions.

Needless to say, I’m really tempted to try this. Probably not for work, but for my hobby projects. What appeals to me about it is that it marries the old school with the new. A perfect synergy between a command line / vim geekery and new and shiny ultra-mobile thin client. The way into the future, via the good old tried technology of the past.

What do you think? Have you ever tried a setup like this? Let me know in the comments.