One month with Emacs and counting - Part 1

Straight to the point: since mid September I've been
using Emacs, trying to
evaluate whether I was willing to switch from Vim to it.

Yup, that's true, me (user of Vim since the day I've started
using GNU/Linux 10 years ago, (not so) active maintainer in Debian
of vim and related packages, author of some
popular Vim extensions and of vim-addon-manager)
it's considering switching to Emacs. What is worse is that
I've de facto already switched. May jamessan forgive
me.

OK, that was the hardest part to write, now ...

This choice will have an impact on me: partly because I'm quite
sure several fellow DDs will start making fun of this story
, and partly
because as many geeks I've always had strong opinions on the editor war.
Switching side ain't easy.

Hence, I've decided to write a small (2-3) series of blog posts
on the issue, to future memory. The post you are reading is about
why, since a few months ago, I wasn't willing to give Emacs a
try, and how I've changed my mind.

Why I wasn't willing to give Emacs a try, but then changed my
mind

I love knowing tools which can improve my workflow, no matter
the task. Editors happen to be at the intersection of many tasks,
hence knowing well his own editor and feeling
satisfied about it is quite important. This is even more so
for free software hackers which, for a reason or another, happen to
use the very same editor for a lot of different tasks; in my case:
programming, conf file hacking (i.e., playing the sysadm role),
mail writing, and everything in between.

I've started using vi on Solaris around 1998, then
switched to Vim starting from version 4.0, and then followed all
its releases up to 7.0. I consider my "Vim karma" to be quite hight
and I've delivered several talks about using Vim for LUGs and other
free software-related events. Still, I've always been hit bit
several minor nuisances and glitches of Vim which couldn't be fixed
by simple configuration tuning or add-on implementations (more on
this in a future post).

In the quest for the perfect workflow, those glitches have made
me try several times other editors hoping for more satisfying work
environments. Of course Emacs was one of them, which I've tried
repeatedly during the years; the last time was circa 2006.

For one reason or another, after a few days of experiments, I've
always decided to give up with it. Why? Various reasons, listed
below, together with an explanation of what (I think) has changed
since then.

1. Poor Unicode/multibyte support. Support for
   whatever Unicode encoding was close to null. It was not available
   in the legacy editor, and you had to use something called MULE, to
   be specifically enabled. That was so 60's, and rather hard to
   use.

   Now (apparently
   starting from Emacs 22.1, June 2007) finally you have built-in
   Unicode support and the needed two variables for setting the input
   encoding and the file encoding, which is basically all you need.
   Looks easy once you have it ...

2. Lack of "modern" UI toolkit support. Yes, I do
   live in a console and invoke my editor from it, but nevertheless
   for long coding sessions I do also love having a nice GTK+ window
   containing my editor using settings which smoothly integrated with
   the graphical settings of my desktop environment. Maybe I'm getting
   old, maybe GNOME has changed my perceptions, but why the heck I had
   to tolerate different monospace fonts in my
   gnome-terminal wrt my GUI editor I never understood.
   Firing up Emacs was like getting back in time of 15 years, and if a
   geek having a maximized terminal on most of its workspaces had this
   feeling, then something was really wrong.

   This has changed: starting again from Emacs 22.1, the editor has
   frown support for that "bleeding edge" technology called GTK+.
   Finally you can use Pango font faces and avoid the time travel
   feeling when switching from a terminal to your GUI.

3. "Dead upstream" syndrome. As we all know by
   experience, choosing a free software product is not only a matter
   of evaluating bugs and features, there are other environmental
   factors. A notable example is how active upstream is. A few of us
   will use a product affected by the "dead upstream" syndrome. That's
   exactly what I was feeling about Emacs. The first argument I can
   offer to back that feeling is again the Emacs
   release history (noted that "small" hole between 2001 and 2007?
   Rest In Peace release early, release often ...).

   The second argument is the bug tracking system: there was none,
   bug discussions happened only on the development mailing list and
   the bug tracker was a text file on CVS! (Yes, Vim doesn't have a
   proper BTS either, but I was looking for reasons to switch from it
   and hence looking for something better in several respects.)

   That has changed completely, as I discovered only at this year DebConf thanks to
   gismo. 2007 has enjoyed 1 Emacs
   release and 2008 already two. They do have
   a BTS now and guess what? is dear old debbugs. According to my first
   experiences as Emacs bug reported the maintainers are very reactive
   and also friendly in dealing with bug reporters. Finally, also
   keeping up with snapshot releases in Debian is entirely trivial,
   thanks to Romain's
   repository.

4. Poor performances & memory consumption.
   This goes in the direction of probably the most popular joke used
   by Vim zealots in the editor war: Emacs is a nice operating
   system, but lacks a good editor, or something such.

   In the past I had the impression that starting Emacs was really
   slow and that generally the memory footprint was too high to be
   acceptable. You know what: starting a full-blown
   gvim with a good deals of add-ons (and I used quite a
   lot of them, that's why vim-addon-manager
   was born) is not that faster. And on the contrary, firing up an
   emacsclient
   is way faster than starting up a new gvim
   instance.

   Regarding memory consumption Emacs is still "gaining" the
   battle. Still, one has to keep in mind the different workflow: with
   Vim you are encouraged to enter and exit the editor (not without
   drawbacks, as I'll discuss in a future post), while with Emacs you
   always use the same one. It turns out that via
   emacsclient the resulting feeling is the same as
   having multiple editors (as you can fire them up as separate
   windows or in separate consoles), still sharing all user
   memory.

   A final comment on memory consumption while looking at my
   top sorted by decreasing RSS memory: the top process
   is xulrunner (from the browser) with 356Mb, then Xorg (159M),
   pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ...,
   Emacs shows up with 51 Mb at the 7th position. Yes, it is not the
   thinnest editor in the world, but on average machine it doesn't
   really matter at all.

In the next post: how to switch from Vim to Emacs, without
loosing your mental sanity. (Whether I did succeed wrt sanity is up
to the reader to judge.)