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.
-
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 ...
-
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.
-
"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.
-
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.)
The venue looks great. It's full of nice spots for impromptu
chats, beers, and the like, which I love. I had a good lengthy
recovery sleep and I'm ready for the usual DebConf fun to begin.
Plan for today is simple: dismantle DPL backlog accumulated during
the trip and in the frantic 10-15 days before it.
If you are at the conference and willing to discuss, chat, or
simply share a beer: do not hesitate! For something less informal,
Neil is also organizing an in person "ask
the leader" session here; feel free to propose
questions to him and make me have a hard time answering
them.
See you around.
The venue looks great. It's full of nice spots for impromptu
chats, beers, and the like, which I love. I had a good lengthy
recovery sleep and I'm ready for the usual DebConf fun to begin.
Plan for today is simple: dismantle DPL backlog accumulated during
the trip and in the frantic 10-15 days before it.
If you are at the conference and willing to discuss, chat, or
simply share a beer: do not hesitate! For something less informal,
Neil is also organizing an in person "ask
the leader" session here; feel free to propose
questions to him and make me have a hard time answering
them.
See you around.
On Wednesday I got DAM approval and since Saturday late evening 
NP: 
, 
. If you can't wait for the next Vim
upload take my current