Vim - The Distraction Free Editor

Vim - The Distraction Free Editor

A little while ago, I took to Twitter in a sense of jubilant excitement announcing that VIM was THE distraction-free editor. As it’s been quite some time since, I honestly don’t remember exactly what it was that motivated me to do so.

However, not so long after I’d sent the tweet, Stuart Herbert replied asking why I felt that way. His tweet lead me to think, deeply, on what I’d written, for some time. And for all of that time I’d meant to take the time to further clarify exactly what I meant.

However, owing to a full workload, family, and ongoing health issues, I’ve not felt that I had the time, until now. So today, I’m going to do that.

But first, a little bit of clarification.

What is Distraction-Free?

Distraction-free is a term that’s been going around for some time, often used to describe software which allows you to work with a minimum of visual clutter and, by logically extension, distraction.

By visual clutter, I specifically mean such things as buttons, toolbars, and other UI elements. One of the best implementations of it — at least that I’m aware of — is Writer, by iA software.

iA Writer, a distraction-free editor

You can see here that, by default, only the writing area is visible. There are options available for highlighting, word and character count, and time spent writing, which you can see below. But by default these are not visible.

iA Writer with the tools visible

What’s more, you can go one step further, into what they call “Focus Mode”. As you can see in the image below, it blurs out everything except the active sentence. That’s quite handy, but ironically I find it sometimes more distracting than not having it.

iA Writer in focus mode

Then there’s the distraction-free mode in PhpStorm, my current IDE of choice. Normally, as you’d expect with software-development software, by default there are a hell of a lot of options available to choose from.

PhpStorm in normal mode

Given there’s so many tasks involved in making software, such as writing, debugging, testing — as well as the other related tools — this is perfectly logical. However, you don’t always need them to be present.

Sometimes, you just want to focus on the section of code you’re working on. When so, enter Distraction-Free mode, which you can see below, and you can do just that.

PhpStorm’s distraction free mode

Similar to Writer, it removes all the panels, toolbars, menus, and buttons and just shows you the code.

Now to VIM

Why is it better?

Is it?

Good question.

In the course of writing this article, I’ve come to wonder if my overly-jubilant expression of passion in that original tweet was actually correct. I’ve even come to wonder what I truly meant and was feeling. So let’s explore the point.

Vim - THE distraction free editor

The screenshot above shows a screenshot of VIM where I’m writing the current article. As with Writer and PhpStorm in distraction-free mode, it shows almost nothing other than the prose I’m writing.

It does show the file name, file type, word count, position in the text, line and character count. So for an apples to apples comparison, Writer offers less visual distraction. So, on that score, Writer comes out ahead.

Given that, thinking this through further, what I should have tweeted was something more comprehensive, more nuanced. However, given the 140 character limit of a tweet, that’s somewhat hard to do.

Sure, I could write a series of tweets, but I don’t like how they’re commonly split up into a longer thread. Given that, I’ll express more nuanced thoughts here.

So Why Do I Love VIM?

I love VIM, as it lets me write, yet does provide me with suitable assistance as and when necessary. Writer does that too, you can correctly argue. Yes. But Writer’s only for Markdown content.

I don’t write just in Markdown. I commonly write in a number of formats; including Markdown, Asciidoc, reStructuredText, and plain text. I also, increasingly use VIM to write code; whether in PHP, Go, Ruby, or Python.

But with Writer you don’t need to do anything. Just install it, start it, and get writing, you might be shouting. And, shouting aside, right you’d be.

I also hear my good mate Gary Hockin saying something similar about PhpStorm. And right he is as well.

Initially, VIM doesn’t do near what I, nor any other writer or software developer needs it to. It does do a lot however. But that’s where it can be a wonderful thing, if you’re willing to invest the time and effort to learn and customise it.

This is what I was really excited about when I wrote that tweet. It was the pride that I felt at the investment I’d made at customising an application to do just what I needed it to do. It was the satisfaction that it nearly perfectly suited the work that I do on a daily basis.

To dive in a bit, among other things, the configuration offers the following functionality:

  • Intelligent support for PHP, Go, C/C++, Python, Ruby, Node/JavaScript, and Bash
  • Support for the Markdown, Asciidoc, Makefile, Twig, and reStructuredText file formats
  • Refactoring support
  • Code documentation and commenting support
  • Code beautification support
  • Advanced Git support
  • Writing support, including advanced spell-checking and grammar checking

But it also went further than that.

VIM is Also Synonymous with Linux

Ever since I’d first gotten into Linux in 1997 — after a disastrous experience with Windows 95(a) — I’ve known about the 30-year old veteran application that is VIM. Every UNIX and Linux box that I’ve ever worked on, except for Docker containers more recently, has always had it available.

If you have more than a passing interest in Linux or UNIX it won’t be too long before you begin hearing about it. But usually in the same breath as it’s regarded so highly, it’s also reclaimed as being such a difficult and frustrating tool to use.

So there’s another reason that I felt so proud; I felt that I had significant “street cred”, if only in my own mind.

This 30-year old application, one that comes with every flavour of Linux and UNIX, one that’s regarded as damn hard to use, I not only had become comfortable with, I’d become proficient in.

I even created a GitHub repository with my own configuration!

Disclaimer: I didn’t write it from scratch. I based it on a series of other configurations, primarily inspired by Matthew Weier O’Phinney and Evan Courey. Generous hat tip to them.

In Conclusion

So Stuart, if you’re reading, this is likely what was really going on in my mind when I wrote that tweet. I didn’t fully appreciate it at the time. But I do now.

That said, while I felt — and still feel — the need to grow ever more proficient at VIM, I don’t expect anyone else to. If I’m one of a small number of people who get a kick out of it, who see it as a valuable skill, who think that it’s still one of the best tools around, then I’m fine with that.

I don’t expect anyone else to share my passion. But if you do, I’m more than happy to help.

Are you a VIM user? Do you share my passion? Do you hate VIM and wonder why people even use it anymore? Either way, I’d love to hear your thoughts in the comments.

CC Image Courtesy of McKay Wei on Flickr

You might also be interested in these tutorials too...

Want more tutorials like this?

If so, enter your email address in the field below and click subscribe.

You can unsubscribe at any time by clicking the link in the footer of the emails you'll receive. Here's my privacy policy, if you'd like to know more. I use Mailchimp to send emails. You can learn more about their privacy practices here.

Join the discussion

comments powered by Disqus