Vim vs. Emacs (Part 3)

See parts 1 and 2.

Some more comments after using emacs for a while:

I finally found the perfect tab completion solution. It took way too much searching for how awesome it is. It’s called auto-complete-mode. The best way to get an idea of what this is is to watch this screencast. Basically, it shows you a completion list automatically. It uses the TAB key to do completion (to me, this is a no brainer, but for some reason, no other completion extension that I found did this, requiring you to do all kinds of nonsense in your .emacs file). It’s got cool features like simple fuzzy matching and intelligent matching (so the first completion is what you tend to use, instead of just the first one that matches). To quote the author, “a goal of auto-complete-mode is to provide a system that does what users want without any command.” I couldn’t agree with that goal more. If you install it, I recommend adding (define-key ac-mode-map (kbd "M-TAB") 'auto-complete) to your .emacs, so that you can use M-TAB to force the completion menu to come up. This generally happens automatically, but I think this is the only way to get fuzzy matching, for example. Actually, you can also just use (ac-set-trigger-key "TAB"), which intelligently sets TAB to complete or indent, based on which one you more likely want. This seems to work pretty well to me.

Speaking of indenting, emacs has a pretty nice indentation feature for Python. You just press TAB repeatedly, and it cycles through all the syntactically legal indentations. I find this to be more useful than the usual TAB indents behavior of most editors. Note that by default, it won’t automatically indent, even with trivial indentations (i.e., keeping the previous indentation). This is easy to fix, though. Just add (define-key global-map (kbd "RET") 'newline-and-indent) to your .emacs file. This will make RET do the same thing as C-j, i.e., basically the equivalent of RET TAB.

emacs comes with an extension that lets you work with version control systems, called VC. I don’t use it. I don’t like stuff messing with my git stuff behind my back (sounds like a good way to lose data to me), and I’m good enough with git commands straight that I don’t need the help.

But unlike all the other hundreds of emacs features that I don’t use, this one was seriously slowing down my workflow. It adds three or four seconds to the startup time of emacs when loading from within a git repository. So I did some Googling and added this to my .emacs file:

;; Disable all the version control stuff         
;; Makes emacs load much faster inside git repos 

(setq vc-handled-backends nil)

(unrelated: Why doesn’t WordPress support lisp as a language for syntax highlighting?)

This disables the version control stuff, making emacs load fast again (virtually as fast as vim, actually).

Speaking of making emacs go faster, make sure you compile all your extensions into byte code. For whatever reason, emacs doesn’t do this automatically, even though compiled files run much faster, and it doesn’t take very long. The easiest way is to use M-x byte-compile-file from within emacs. Just make sure that if you modify the .el file that you recompile the byte code, or it will continue to use the old version.

I finally figured out how to enable mouse support. For whatever reason, Googling got me nowhere with this, so I ended up asking on the help-gnu-emacs list, which was very helpful. The solution is to put

;; ===== Enable mouse support ====
                                      
(require 'xt-mouse)                   
(xterm-mouse-mode)

in your .emacs file. And then it just works. It needs some tweaking (e.g., it doesn’t play so well with momentum scrolling), but at least it works. I thought I was going to hang myself without mouse support. Because frankly, as good as the movement commands are, moving with the mouse is so much easier sometimes (the same is true for vim too, btw).

I compiled the git version of emacs (it’s not very hard btw). I did this to see if the mouse suport “bug” was fixed there, but I’ve gone ahead and kept using it, as it’s nicer. But I didn’t figure out how to configure it to not load in an X window. So for now, I’ve aliased emacs to emacs -nw. I’m sure I just need to add some flag to configure, but I haven’t gotten around to looking it up yet.

I found out how to allow editing in the Isearch mode (again, thanks to the help-gnu-emacs list). You need to install the isearch+ extension, add the following to your .emacs,

;; ===== isearch+ =====         

(require 'isearch+)

and most importantly, you need to edit the file and uncomment all the commmands you want to allow. If you follow my link above, it goes to my personal dotfiles repo, where I’ve already done that.

On a related note, this is the first of several emacs extensions I’ve installed that I’ve edited the extension file itself for. The rest, I just had to add some code to .emacs. In most cases, there was already a variable or suggested code snippet to add to .emacs to get what I wanted.

On the other hand, with vim, I had to edit virtually every extension I installed to make it do what I want. I’m not sure what this means, though. It could be a statement about one of many things: how the emacs community provides nicer defaults, how the vim language is easier to use, and hence more inviting for me to edit the files, or how I haven’t gotten around to messing with certain things yet.

If you do a lot of work with LaTeX, check out AUCTeX. I haven’t used it enough yet to say much about it, but from what I’ve played around with, it’s pretty awesome. And if you use a windowed version of emacs, it’s got a really awesome preview mode.

If you’re bored, check out the predictive extension. It’s actually not as helpful as you’d think (unlike the very similar auto-complete-mode module mentioned above). But it’s kind of cool to turn on and play around with when you’re typing something. Maybe you’ll learn new words or something.

I could go on and on. I haven’t mentioned the most basic customizations (like how to setup four-space tabs). If you are starting to use emacs, I recommend going through M-x customize, and reading my .emacs file. And my best advice: if you want emacs to do something, first do M-x customize and search for what you want (EDIT: apparently searching customize requires emacs 24, i.e., the development version). If you don’t find what you want there (and you will surprisingly often), search Google. There are so many emacs users, that the chances of someone else wanting what you want are very likely. I’ve found the results from the emacs wiki to be particularly helpful. And one more thing: if you find an extension you like, double check first to see if it’s not already included in emacs. Emacs seems to like including good extensions in future releases, so an older extension has a good chance of already being included.

Some emacs questions:

I tried (define-abbrev global-abbrev-table "Ondrej" "Ondřej"), so that when I type Ondrej it give me Ondřej. But it doesn’t work. Is this a bug or what? If I do (define-abbrev global-abbrev-table "foo" "bar") and type “foo”, it turns into “bar”, but the above leaves Ondrej alone. EDIT: I guess this was an emacs bug. It doesn’t seem to be there any more (perhaps it was fixed with the git version or something).

Is there a way to reload .emacs without closing emacs? I’m doing that a lot these days. EDIT: I found it. Do M-x load-file RET ~/.emacs

Is there a good emacs equivalent of the vim tag list plugin (thanks for commenter Scott for pointing me to that in the first place)? I just want something that lists all the class and function definitions in a Python file in order, so I can easily jump to the one I want, or just get an overview of the file.

This Tuesday will mark the point where I will have spend as long using emacs as I did using vim. But already, I feel more competent with emacs. I won’t repeat what I said in my last post, but I just want to say that the ability to edit and write at the same time makes me way more productive. The fact that it uses keyboard shortcuts that I’m already used to probably helps a lot too. Even so, I’ve not used any kind of cheat sheet for emacs (since I never really found any that were any good), and yet I feel like I’ve memorized more key commands now than I ever did with vim, for which I did use a cheat sheet.

So I really don’t see myself going back to vim at this point.

I’m actually surprised. Virtually everyone I know who uses a command line editor uses vim. It’s definitely the more popular of the two. But having tried both, I can only speculate as to why. Vim has a much higher learning curve than emacs. Everybody grows up learning how to write text in editors like Microsoft Word, TextEdit, Notepad, etc., that all work fundamentally like emacs: if you type text, it enters the text. If you want to do advanced editing with the keyboard, you hold down some meta keys and type chorded keyboard shortcuts. The vim modal editing methodology is so different from this, that it surprises me that so many people go to the trouble of learning it (I mean, to the point that they are more efficient with it). I can see the benefit over GUI editors, which have nothing on either vim or emacs with regards to customization, or just the plain editing power that is really necessary for coding. My guesses why people use vim:

They are shown vim first, so just use it.

They are turned off by the massiveness of emacs (it seems contradictory to me, since the whole point of using a command line editor is to get more power, but I could see it).

They are turned off by emacs lisp.

Some combination of those.

Maybe the vim users out there could comment why they use vim. Am I missing something? Or are your heads just wired differently from mine? And if you use emacs (or anything else), I’d love to hear from you too?

At any rate, I recommend that anyone who wants to give command line editors a chance do what I did: learn both vim and emacs. My blog posts should be enough to give you some good advice. I went cold-turkey, and I recommend that you do too, but only do it if you won’t have any important editing to do for a few weeks, as your editing rate will slow down a lot as you are learning for both editors. And even though I think I am going to stick with emacs, learning vim was still valuable. Unlike emacs, vi is part of the POSIX standard, so it’s included in pretty much every UNIX distribution. I’ll be glad when I find myself on a minimal command line and know how to use a decent text editor. And anyway, you can’t really know which one will be your way until you try them both. I really thought I would end up using vim, as it was so popular among all the people I know who use command line editors. But I guess there is only One True Editor.

EDIT: I found out how to make emacs really fast. The key is to run one process of emacs in daemon mode, and have the rest connect to that. Then you only have to wait for the startup once (per computer session). To do it, just set your EDITOR to 'emacsclient -a "" -nw' (and you might also want to alias emacs to that as well). What this does is connect to the emacs daemon. The -a "" starts one if it isn’t already started (you can also do this yourself with emacs --daemon. If you only want to use the daemon version if you’ve specifically started it, replace "" with emacs. This will connect to the daemon if it’s running, and otherwise just start a new emacs process.

The -nw keeps it from running in window mode. Remove this if you use the GUI version of emacs. This is necessary to make it work correctly with multiple tabs. This is so fast that you should never really even need to use C-z to quickly exit emacs. C-x C-c is just fine, because reopening will be instantaneous. I like this because I was starting to accumulate background emacs processes that I forgot about.

This probably requires a fairly new version of emacs, possibly even the development version.

Vim vs. Emacs (Part 2)

As I noted in part 1, I have decided to switch to a command line text editor. I decided that, to be fair, I would try both vim and emacs. And to force myself to learn them, I decided to use them cold-turkey.

Since I’m going cold-turkey, I am doing this over my break from classes, so that I can weed out any difficulties during a period when I can live with slow text editing if necessary. This is a one month break. I have reached (roughly) the half way point. For the first half, I used nothing but vim to edit text. Now, I will use nothing but emacs.

Now that I’ve stopped using vim (for now anyway), my view of it isn’t much different from what I wrote in the first part. A lot of things there were addressed by commenters (or rather commenter). I still feel that it’s not an a method of text editing that fits my head. My entire life, I’ve used text editors where typing inserts text, and various control characters do things like move around faster.

Enter emacs. It does exactly this. Also a ton more.

I’ve only been using emacs for two days, but here are my impressions so far:

The tutorial is better. When you start emacs, it tells you how to start the tutorial. Just type C-h t (if you don’t already know, in emacs C- means CTRL- and M- means ALT-). Like I said last time, the very first thing you learn is how to scroll by more than one line at a time. That turns out to be a very useful thing to do. Also, the emacs tutorial did a better job of explaining how to use multiple files at once in emacs, which is something that I still don’t really know how to do very well in vim.

I have to give the vim tutorial some credit for one thing, though. It has better interactive examples. For example, in the vim tutorial, you have stuff like

  1. Move the cursor to the second line in the phrase below.
  2. Type  dd  to delete the line.
  3. Now move to the fourth line.
  4. Type   2dd   to delete two lines.

--->  1)  Roses are red,
--->  2)  Mud is fun,
--->  3)  Violets are blue,
--->  4)  I have a car,
--->  5)  Clocks tell time,
--->  6)  Sugar is sweet
--->  7)  And so are you.

whereas in the emacs tutorial, you just have

>> Kill a line, move around, kill another line.
   Then do C-y to get back the second killed line.
   Then do M-y and it will be replaced by the first killed line.
   Do more M-y's and see what you get.  Keep doing them until
   the second kill line comes back, and then a few more.
   If you like, you can try giving M-y positive and negative
   arguments.

which is a little more vague. So I have to give vim credit for that.

Everything’s a buffer. This line from the emacs tutorial really stuck with me: “ANY text you see in an Emacs window is always part of some buffer.” Emacs has really a awesome editing model, even simple things like M-f and M-b to move around words at a time, or M-DEL to delete whole words make things way faster. Vim of course has all of these too, albiet in a different way, but they aren’t everywhere. In emacs, everything is a buffer, which just means that everything supports all the standard emacs commands. So if you type M-x (roughly the equivalent of vim’s :) and start typing a command, you can move around and edit your command with emacs commands. One of the things that bothered me about vim was that when I was typing something with :, I couldn’t use vim’s text moving/modifying commands to manipulate the text. Typing ESC just canceled the command.

Exceptions: There are at least two exceptions I’ve found to this rule. First, if you do a search with C-s or C-r, no control commands work. If you type a search string, and then type M-DEL to try to delete the last word in your search string, you will instead delete the word where the cursor is! The solution I think is to use something like M-x re-builder instead. This was a little slow in my tests.

Second, the emacs manual is presented in the info program, which uses completely different key commands from every other program. This irked me quite a bit, because as soon as I finished the emacs tutorial, it pointed me to the manual, which was in info. Then, the first thing in info is a tutorial on how to use info! I opted to skip this. If I need any information on emacs, I’ll just do a Google search anyway, so I found this to be a waste of time.

It’s a little slower. I do notice a speed difference between emacs and vim. vim is much more lightweight, and it shows. Starting up emacs takes a second or two. Also, since a lot of the features are more interactive, they suffer from a speed delay. It’s not nearly slow enough to be a serious issue, though, and it’s still way faster than the GUI program I was using before (start up time).

The emacs tutorial suggests using C-z whenever you want to only temporarily close emacs. This seems like a good idea, and has worked pretty well for me so far (though I still usually close the whole thing with C-x C-c out of habit).

On a related note, I noticed that doing type-ahead while waiting for emacs to start up didn’t always work, whereas it always worked in vim (I do this, e.g., when waiting for the editor to start up when writing commit messages).

It’s way more user-friendly. Note that this is of course a relative term. I mean more user-friendly than vim, and pretty user-friendly for a command line program. Obviously, the most user-friendly text editors are the GUI ones used by the majority of the population (for that very reason). Actually, both vim and emacs are user-unfriendly in that if you accidentally open them and don’t know what they are or how to use them, you have no idea how to close them. But even less (i.e., man) is technically like this.

I’m not even referring to the different editing “modes” of the two editors, though you could easily argue that emacs style editing is more user-friendly than vim style editing. What I mean here is that emacs interaction is nice. When you type : in vim, start typing a command, and type TAB, it enters the first completion, regardless if it’s unique. Pressing TAB multiple times give the rest. In emacs, if you type M-x and start typing a command and type TAB, it pops up a temporary window with the list of all completions. It even colors the next character, so you can easily see what to type next to get what you want. As soon as you enter the command, the window disappears. (yes, I know about CTRL-D in vim, but to me tab completion should always work like it does in bash: complete characters if and only if they are unique in the list of completions)

By the way, when I said everything’s a buffer, I mean everything. If you want, you can exit the M-x entry (type C-g), type C-x C-b to show the list of buffers, C-x o to switch to it, scroll down to “Completions”, press Enter, and actually get in the completion list, as a buffer (there’s probably a less complicated way to get to it, by the way). You can then do whatever your heart fancies with it (save it to a file, copy it, whatever).

Customization is harder. This was expected, since I already knew that emacs used lisp. vim uses a language that is really easy to understand. I was able to modify all the vim plugins I installed very easily. If you want to change a setting globally in vim, just Google it and add one line to your .vimrc. In emacs, everything is in Emacs Lisp. I suppose prior experience with Lisp would probably help here.

In the vim tutorial, near the end, it told how to create a .vimrc file, and even gave a very useful sample one as a starter. In emacs, it took me a while to figure out how to do the equivalent (it took me a few Google searches just to figure out that the name of the configuration file in emacs is .emacs).

Actually, the emacs equivalent is way better than in vim, but it isn’t really mentioned anywhere. It took me probably a dozen Google searches before I learned about it (granted, I was looking for things in the same way I did for vim, lines to add to .emacs). What you have to do is type M-x configure. This opens what is basically a huge preferences dialog for emacs. You can then go through and set just about every settable emacs setting from there. The interface is very nice, as it’s interactive and tells you all about each setting. And you never have to touch Lisp. I’m still going through it, so I can’t comment more on it yet. But I recommend doing M-x configure as soon as you have finished the tutorial and have gotten used to editing with emacs, as you are invariably going to want to change some things (though I should note that emacs generally has nicer defaults than vim).

Better text editing methodology? Like I’ve already mentioned a bunch of times, the emacs editing model seems to fit my head better than the vim model. In emacs, you type text, and it inserts the text. If you want to do some advanced modification or move around, you type a control sequence. In vim, you type characters, and it does modifications or moves around. If you want to type text, you type i (or one of a few other characters) and type it. Then, if you want to move around or modify the text, you have to press ESC. This so-called “modular editing” doesn’t seem to work for me. For one thing, I like to rapidly switch back and forth between these two “modes” (editing and inserting) when I write things. I type too fast and write something wrong, and have to delete some stuff. The M-DEL emacs command is probably my most used (this also works in Mac OS X text dialogs, so I’m used to it already). In vim, there is CTRL-w and a few others, but if I want to do something more advanced, like rearranging a sentence, then half of my key presses would be ESC or i, i.e., just moving between the modes. In emacs, I can always have my pinky by Control and Alt (especially as soon as I remap CAPS-LOCK to Control).

Also, it really irks me how in vim, if you are at the end of a line and press l (or right-arrow), instead of moving to the beginning of the next line, it beeps! In emacs, if you are at the end of a the line and type C-f, it moves to the beginning of the next line (actually, it technically moves just beyond the line, in case you want to append, which is another annoying thing about vim: you have to use A, not i, to add text to the end of a line).

Well, that’s it for now. I will hold off on the questions until after I go through all the customizations, as it seems that, unlike vim, emacs has many things already built-in (but we already knew that, didn’t we :). So I have just one question for readers: does anyone know of a really good emacs cheatsheet? The one I used for vim was really awesome, but I haven’t found anything equal for emacs. I find myself searching the tutorial whenever I forget something, which is not very efficient, so I would appreciate something better. Otherwise, I’ll just find something decent and print it out, as it would be better than nothing.

And if anyone cares, you can see what I’ve got for my .emacs file so far at https://github.com/asmeurer/dotfiles/blob/master/.emacs.

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 11,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 4 sold-out performances for that many people to see it.

Click here to see the complete report.