Vim in Atom

I installed Atom today as I needed some kind of IDE without forking over a lot of money, or spending time on configuring something. This meant trusting the claim that it works straight out of the box.

Later as I considered whether or not I would use it beyond the one task I needed it for, I googled “vim in atom”. This made me realise that I’ve become acclimatised to Vim to the point that I want its functionality in anything I use, and also begin to wonder why I didn’t just stick to using “vim in vim“.

Luckily, the search results page contained answers to both of these questions.

Why do I use Vim? Partly to score NeckbeardHacker kudos from Unix greybeards, but mainly because it allows you to compose commands so neatly from smaller “words”, as discussed in Why Atom Can’t Replace Vim by Mike Kozlowski. Having become used to hitting commands for “delete three words” (d3w) and suchlike, it’s hardly desirable to go back to Ctrl+This+That shortcuts.

But I’m not a Vim power-user, and as such I want more. Thus, my second question; why don’t I just use vanilla Vim? It lacks a shiny GUI, with lovely nested directory trees, and the plays-well-with-others style of a typical modern IDE. And so I’m waiting for a suitable neovim, or until then, Vim in Atom.


prurient having, or characterized by lascivious or lustful thoughts, desires, etc. ochre a moderate yellow-orange to orange colour moribund in a dying state, near death bibulous fond of or addicted to drink sepoy (formerly) an Indian soldier in the service of the British venal open to bribery impeach to accuse a public official, before an appropriate tribunal, of misconduct in office acquiesce to submit or comply without protest widdershins in a direction contrary to the usual, e.g. anticlockwise diatribe a bitter, sharply abusive denunciation, attack, or criticism

(definitions copied or adapted from

On specifications that can generate code

One might argue that a book about code is somehow behind the times—that code is no longer the issue; that we should be concerned about models and requirements instead. Indeed some have suggested that we are close to the end of code. That soon all code will be generated instead of written. That programmers simply won’t be needed because business people will generate programs from specifications.

Nonsense! We will never be rid of code, because code represents the details of the requirements. At some level those details cannot be ignored or abstracted; they have to be specified. And specifying requirements in such detail that a machine can execute them is programming. Such a specification is code.

From Clean Code, Robert C. Martin.