Skip to main content

Vim: Why I Like Vim

I'm not trying to start a flame war. I'm trying to be honest and open minded. Here are things I really like about Vim:
  • I actually really like modal editing. Like most Vim experts, I spend almost all my time in command mode. I exit insert mode as soon as I'm done adding new text. That means I don't have to spend a lot of time holding down the control (i.e. caps lock) key.

  • I find hjkl to be a very convenient replacement for the arrow keys. They're only one key press each, and they're on the home row.

  • Vim's notion of combinable commands are intuitive, fast, and powerful. For instance, >aB means shift the block around the current cursor to the right. It is not a function in and of itself. Rather, it's a combination of a few pieces. Like in UNIX, you use small tools and put things together to achieve big things. >aB is like a UNIX pipeline in a way.

  • I love the fact that Vim has simple syntax highlighting built in for even very strange languages. Sometimes I don't need a full mode. Nice syntax highlighting is enough.

  • I like the fact that it's trivially easy to tell Vim that for such and such a type of file, it should be indented in such and such a way. The type of file need not be code. Even in cases where there is no special mode, Vim can still be very helpful in making the tab do what I want. Sometimes I don't want the editor to indent the code for me. I want it to help me indent the code by understanding how I want the tab key to behave. Of course, smart indentation is available for mainstream languages if I want it.

  • I like that Vim has a builtin scripting language, but it can also be scripted with Python. Unlike Vi, it's enough like Emacs that I find it to be a very happy middleground.

  • I like the fact that Vim has such a nice infrastructure for supporting multiple widget toolkits. It looks reasonably good looking on any platform.
Ok, like I said, this is not a flame war. If you say nice things about your editor, that's cool too.


jjinux said…
I really trust Brandon Golm's opinion on this issue since he's really good with both Vim and Emacs. He has finally convinced me that since I am already really good with Vim, switching to Emacs isn't going to make me any more productive.

Apparently, when you want to chop up a log, sharpening one axe helps, but sharpening up several axes and trying each one of them doesn't help ;)
Unknown said…
As a long-time emacs user (since 1985) I always thought vi's modes were some sort of throw-back to the dark days of early editors.

Recently, I implemented a vi mode for Wing IDE and I must say that now I'm impressed w/ the idea of modes and the way that commands can be combined. It really is a very nice design and I think I like it better than emacs. Who knows...

While I no longer use emacs very much (I mainly use Wing's emacs mode instead) alas my fingers are firmly emacs fingers by now and I've found it very hard to convert. But from time to time I work on it just the same.
Anonymous said…
"I find hjkl to be a very convenient replacement for the arrow keys."

This also helps to sharpen your nethack skills.

Of course, there's always:
jjinux said…
> Recently, I implemented a vi mode for Wing IDE and I must say that now I'm impressed w/ the idea of modes and the way that commands can be combined.

Oh, hey, I've used your software ;)
jjinux said…
> alas my fingers are firmly emacs fingers by now

Yes, it seems to take a couple weeks of concentrated effort to switch.
David Goodger said…
Both Emacs & Vi are sophisticated, complex tools. I agree that once you're familiar with one, there's not much point learning the other. I've been an Emacs user for a long time, and Vi just feels wrong to me -- but I'm sure the opposite also holds.

No biggie.
Anonymous said…
I'm not an Emacs superuser, but I was using it as my editor until recently.
I had to do some work on a stripped down Linux system where Emacs wasn't available. vi felt awkward, but I picked up enough to get started.
Not long after, I had to clean up a bunch of really messy Python code (that I under duress would admit to having written) using pylint. In command mode, there is probably nothing quicker for moving text around and neatening things. I'm pretty happy with Vim and GVim (on Windows).
I still use Emacs all of the time as an editor, as a calculator, as a calendar . . . etc. etc., but for editing code I'm a bit of a vi convert.
My 2 cents
jjinux said…
> In command mode, there is probably nothing quicker for moving text around and neatening things...I still use Emacs all of the time as an editor, as a calculator, as a calendar . . . etc. etc., but for editing code I'm a bit of a vi convert.

Exactly. Emacs is great if there's a mode that does something that you need, say editing gettext catalogs. But when it comes to simply slinging text around really fast, you can't beat Vim in command mode.
jjinux said…
> Both Emacs & Vi are sophisticated, complex tools. I agree that once you're familiar with one, there's not much point learning the other.

> No biggie.

That is the conclusion I have come to. Thanks for confirming it.
Unknown said…
as a former sysad: when your big *nix-machine has a bad crash the vi
is often all you had :-)
(ist in your first-aid-pack)
Dave Kirby said…
One of my favourite Vim (and Vi) commands is :global to do a mass action across a file. For example:


displays all the print statements in a file.

:g/^\s*print/ d

deletes all the print statements.

:g/# TODO:/ .,/^\s*$/ w! >> tmp.txt

Appends to tmp.txt all blocks of lines starting from a TODO comment to the next blank line.

By combining :g with the other ex command you can do in one line complex processing that would require a full blown script or lots of manual work in other editors.
jjinux said…
Ah, like sed, but from within Vi. Thanks!
Noah Gift said…
I give you 6 months and you will be mixing vim with textmate. The mac crack is way too strong for you shannon :)

Seriously, I love vim, cli only please, but I have been mixing a bit of textmate into the picture when I need do hordes of cut and paste.
jjinux said…
If you use Vim, why not use MacVim? It works perfectly well with cut-and-paste. I really like it.
Noah Gift said…
MacVim is like a low fat cookie. You need to either eat a thick homemade chocolate chip cooke, and REALLY have a cookie, or skip the cookie all together :)

Actually MacVim is ok, I use it sometimes, but I am exploring my proprietary software side, because I am not supposed to. That is half the fun.

I do want to play with Wing IDE again too...
jjinux said…
Wing IDE can result in some real productivity gains for Python. Unfortunately, I've heard that it looks terrible on a Mac.
jjinux said…
Ugh, I'm obsessed with Emacs again. You know the saying, "Emacs is a pretty good operating system which only lacks a decent editor."

* I don't want to use Emacs as a Web browser. Such software exists, but clearly it's not as nice as Firefox or Flock.

* I don't want to use Emacs' shell mode. You can't even do things like C-c to kill the current command. The terminal emulation support is definitely not good enough to do something sadistic like run vim in it.

* I am suspicious of using Emacs to control my source control. Sure, it'll support Subversion, but what if I want to use weirder things like Mercurial or Git?

* I don't want to use Emacs as my Python shell. It's not nearly as nice as IPython, although it may be possible to embed IPython.

* I don't want to use Emacs as an IDE. I tried importing the os module and autocompleting on the members, and it couldn't do it right. This is one area where WingIDE really excels.

* I don't want to use Emacs as an email client. I use Gmail. Gmail can do things like quickly find email matching a search criteria even though I have a gig of email stored. Besides, I like having my email off my box.

* I don't want to use Emacs' own shell (esh?). I like zsh.

There are just a couple things that I really need an editor to excel at:

* I want fantastic multi-language syntax highlighting. Emacs isn't the greatest at mixing PHP, JavaScript, SQL, HTML, and CSS in the same file. You shouldn't do that anyway, but even if you do, Vim can still highlight things correctly. Emacs can if you use the right plugin, but it's not standard.

* I want syntax highlighting to be preinstalled for pretty much any weird language I code in. That comes by default in Vim, but not in Python.

* I want to be able to change the way indentation works to match the file type and my whims. This is painful in Emacs. is very helpful, but it still doesn't give me a way to *easily* shift a block of text right or left. In Windows editors, it's highlight, shift, tab. In Vim, it's highlight, greater than, greater than. It follows my shift width settings. It's smart. If Emacs doesn't have a custom mode, life is painful.
jjinux said…
In summary, as a message to my own obsessive self, it's not worth it for me to switch to Emacs unless I can find someone who is as talented with Emacs as I am with Vim and who can help me do the things I already do so well in Vim, IPython, zsh, etc. I think that both Emacs and Vim are both ugly in their own way. Clearly, I'm not going to try something proprietary like TextMate--it doesn't even run on Linux! I'm going to have to just stop obsessing and use Vim as long as the current generation of editors is around. It probably doesn't make sense to rethink this decision every six months like usual. Waiting 5-10 years to rethink it probably makes more sense. It's possible that WingIDE and PyDev might result in a productivity boost, but PyDev in particular always feels so overwhelming. Ugh, I hate being OCD sometimes ;)
jjinux said…
Here's a fun post by a Vim fanatic who is switching to Emacs:
Anonymous said…
I used Vim about five years but a few weeks ago I switched completely to Emacs. My reasons are basically that I started to want more features and Vim just showed its limits. At least this is how I feel, and I'm quite familiar with the extension language too.

For very basic text manipulation I think Vim is the best. If all that one needs is one general-purpose text editor I think Vim is the one. Emacs is certainly very good in this area too but I think it can't beat Vim in terms of ergonomic and fast commands. Emacs, in turn, has more intelligent do-what-I-mean commands. Some commands change their behavior according to mode. For example, sentence forward and backward commands in shell script mode (sh-mode) move to next and previous shell command, whereas in text mode they move by human-language sentences. Intelligent and context-sensitive commands and features increase the editing-speed and ergonomy factor of Emacs - sometimes even over Vim. In addition to that, Emacs' viper-mode brings vi editor inside Emacs so the powerful modal editing is available to Emacs too.

I have been very happy with Vim but in the last couple of months I noticed that I started to do more and more things inside Vim and was looking for plugins to make some tasks more convenient. I got a bit frustrated because certain extensions had some annoying bugs. Often I faced some autocmd errors if I did something unexpected. I know it's quite difficult to program non-trivial extensions for Vim so that they work nicely in all situations. In Emacs many nice features like org-mode, calendar, file manager, email/news client etc. just work. Currently my view is that it would be extremely difficult or even impossible to implement such features for Vim so that they work as nicely as in Emacs.

I also use LaTeX mode (Auctex) quite a lot and it's way ahead of Vim-latex extension. For instance, Emacs can render (parts of) the LaTeX code inside the Emacs buffer. It's really nice to select a math formula and run "M-x preview-region". Boom! The formula changes to its graphical preview. Yes, graphics inside a text editor buffer. With middle mouse button one can switch between the preview and LaTeX code version.

Another nice thing in Emacs is support for asynchronous processes. For example, running "M-x compile" to compile a source code the compiler runs in the background and its output is displayed in an Emacs buffer. "M-x grep-find" is similar. Vim just stops doing anything until the other process exists.

Finally, one thing that I feel is limiting is the development process of Vim. Vim is basically just a one-man project and since Vim's extensibility depends on Bram Moolenaar's (the Vim maintainer) decisions only, I feel Vim's development is "caged", so to say. Vim's design philosophy is to be a text-editing component in a larger set of tools, and not to go much anywhere else. Vim aims to interact well with other tools in the operating system but in practice Emacs does this much better by providing support for asynchronous background processes.

Emacs development has been quite closed too but nowadays it's more open. There are more people involved and more open discussion. And even if this weren't the case, it doesn't matter that much because Emacs' extensibility is not as limited. Many of you know already that Emacs' core is a Lisp interpreter and the Emacs editor is implemented on top of that. Emacs doesn't have an extension language in the same sense as Vim. So called extensions in Emacs operate on the same level as the editor itself. In a way this means that users are on the same level as the core developers. Very powerful.

So yeah, I like Emacs but Vim is still excellent editor. :-)
jjinux said…
Great comment, thanks.

Popular posts from this blog

Drawing Sierpinski's Triangle in Minecraft Using Python

In his keynote at PyCon, Eben Upton, the Executive Director of the Rasberry Pi Foundation, mentioned that not only has Minecraft been ported to the Rasberry Pi, but you can even control it with Python. Since four of my kids are avid Minecraft fans, I figured this might be a good time to teach them to program using Python. So I started yesterday with the goal of programming something cool for Minecraft and then showing it off at the San Francisco Python Meetup in the evening.

The first problem that I faced was that I didn't have a Rasberry Pi. You can't hack Minecraft by just installing the Minecraft client. Speaking of which, I didn't have the Minecraft client installed either ;) My kids always play it on their Nexus 7s. I found an open source Minecraft server called Bukkit that "provides the means to extend the popular Minecraft multiplayer server." Then I found a plugin called RaspberryJuice that implements a subset of the Minecraft Pi modding API for Bukkit s…

Apple: iPad and Emacs

Someone asked my boss's buddy Art Medlar if he was going to buy an iPad. He said, "I figure as soon as it runs Emacs, that will be the sign to buy." I think he was just trying to be funny, but his statement is actually fairly profound.

It's well known that submitting iPhone and iPad applications for sale on Apple's store is a huge pain--even if they're free and open source. Apple is acting as a gatekeeper for what is and isn't allowed on your device. I heard that Apple would never allow a scripting language to be installed on your iPad because it would allow end users to run code that they hadn't verified. (I don't have a reference for this, but if you do, please post it below.) Emacs is mostly written in Emacs Lisp. Per Apple's policy, I don't think it'll ever be possible to run Emacs on the iPad.

Emacs was written by Richard Stallman, and it practically defines the Free Software movement (in a manner of speaking at least). Stal…

JavaScript: Porting from react-css-modules to babel-plugin-react-css-modules (with Less)

I recently found a bug in react-css-modules that prevented me from upgrading react-mobx which prevented us from upgrading to React 16. Then, I found out that react-css-modules is "no longer actively maintained". Hence, whether I wanted to or not, I was kind of forced into moving from react-css-modules to babel-plugin-react-css-modules. Doing the port is mostly straightforward. Once I switched libraries, the rest of the port was basically:
Get ESLint to pass now that react-css-modules is no longer available.Get babel-plugin-react-css-modules working with Less.Get my Karma tests to at least build.Get the Karma tests to pass.Test things thoroughly.Fight off merge conflicts from the rest of engineering every 10 minutes ;) There were a few things that resulted in difficult code changes. That's what the rest of this blog post is about. I don't think you can fix all of these things ahead of time. Just read through them and keep them in mind as you follow the approach above.…