
Why I Still Use Emacs - markokocic
http://gnuvince.wordpress.com/2012/02/19/why-i-still-use-emacs/
======
mahmud
I don't even know what features of Emacs I use. I have mental intents,
actions, transformations, things I want to do to text, files, buffers, regions
.. my conscious mind has been locked out of the tight-loop, the vicious cycle
of a synapses being fired and keys chorded. It's all muscle memory. The
perfect coupling of an average biological agent, and a bubbly, baroque piece
of antique Lisp technology. Together, battling RSI and worse keyboard layouts,
we sculpt scratch buffers to all sorts of works, many of adequate quality, but
some exquisite.

~~~
entropie
This is poetry.

Yeah, i once gave a emacs introduction in school and people asking me how i do
X, Y. I needed to watch my fingers to tell them.. that was a bit confusing ;)

~~~
lubutu
I have this problem with (random alphanumeric) passwords. When I needed to
input my password on my phone, I actually had to draw a keyboard on a piece of
paper and mime typing it, watching which keys my fingers hit and writing down
the character.

But I don't get this with Vim. I think it's because Vim is a kind of
composable language, so although you don't actually know at the time what
you're doing, if someone were to ask you how you deleted half the line so
quickly, you can work it out: "f)dt:". I think this is the reason I have
trouble learning Emacs: it's not so obvious how commands are composed. There
are some chains like C-h which are, but for the most part it feelings like
there are just too _many_ pieces. I've given it a good shot, and I'll probably
try again, but it just doesn't feel as easy as "'d' to delete".

~~~
lambda
I remember one password that I had committed to muscle memory. I burned my
hand one day cooking, and had to have my hand bandaged up for a week (note to
self: don't try grabbing the steel handle of a pan at 450°F without a mitt). I
couldn't type my password from muscle memory with my hand bandaged. I even
knew the phrase that it was based on, but after many tries, I couldn't
reproduce the exact set of upper and lowercase letters and letter
substitutions that I had used. I eventually had to give up and change out all
of my passwords and SSH keys, because I just couldn't recover my own password
without my muscle memory.

------
einhverfr
I enjoyed the article, even though I am a VIM fan. Many of the same advantages
apply to VIM too.

At the same time I thought it was also like looking into a different culture.
"Easy" meaning "copy and paste what a user tells you?" I guess there is a
different view of easy.

The disadvantages struck me as rather interesting. I am not entirely sure why
you need multithreading in a text editor for example. Perhaps someone could
enlighten me as to when this sort of thing would help. Is it about running a
compile job in one buffer while editing in another?

I also noticed a big reason to use VIM or EMACS over an IDE that seemed
missing and that is that both these editors have tons of features for
gracefully editing large numbers of large files. The IDE's I have worked with
haven't come close here.

For now I will stick with VIM, which I feel comfortable and confident on.
However, seeing folks talk about the benefits of the other is interesting.

~~~
julian37
_I am not entirely sure why you need multithreading in a text editor for
example. Perhaps someone could enlighten me as to when this sort of thing
would help._

Basically, the lack of multithreading prevents any sort of background
processing (unless it can be implemented using an idle hook, which often isn't
possible.)

For example, Gnus (a newsreader which can also be used to read mail from a POP
or IMAP server) locks up Emacs while it is checking for or fetching new mail.
This is quite painful when fetching mail over a slow line or from a slow
server, and causes people to do hacks like mirroring their mail onto a local
IMAP server from where Gnus can fetch it more quickly. But even then, there is
a noticeable pause when the server is accessed.

~~~
johncoltrane
The example you give is the typical Emacs feature Vim zealots like to mock.

If I want to read an email I simply switch to my email client, thus virtually
eliminating (almost) all risks of Vim/Emacs crashing.

~~~
julian37
Gnus is an awesome piece of software and having all of Emacs editing
capabilities at hand when writing mail is fantastic. I'd use it as my primary
mail client if it weren't for the multithreading issue.

Not sure why you'd mock this use of Emacs, after all mails are text and as
such very well suited to being composed with a text editor...

~~~
tmhedberg
My MUA (Mutt) can launch any editor you like for composing mail. I use Vim,
but it would work equally well with Emacs, nano, or whatever you prefer. Mutt
is not alone in this regard.

The point is, you don't have to have embed your MUA inside of your text editor
in order to use your editor for composing mail. There's nothing particularly
wrong with that approach, but it's not the only way to get that benefit.

~~~
_delirium
I agree you don't have to, but if the interaction gets more pervasive, such
that the points of interface become many, it can be easier to just implement
it in the same environment. If you just want to edit mail in vim, that's one
thing, but if you want to be able to use commands in the mail editor to
contextually interact with the rest of a mailbox (highlight a URL and search
your mailbox for other occurrences of that URL, or add an email address to
your address book, to take simple examples), it becomes more like the IDE
case. Either you have to implement the IDE in the editor's scripting language
(the emacs approach), or you need to call out to a number of special-case Unix
tools to implement each of the hooks (the vim approach).

~~~
oscillator
I write all my work e-mail in GNU Emacs and use the Emacs VM mailer.

Because it's all inside Emacs, text from other contexts -- code, shells,
mailboxes, and compiler and tool output -- can be accurately and quickly
pulled into the messages you compose, improving the content and reliability of
what you're saying in mail.

For example, if I want to use a complex identifier from a source file I've
just looked at, I can autocomplete it (M-. or find-tag) quickly from a
substring. I can choose autocompletion suggestions simultaneously from all
contexts.

Obviously, copying and pasting regions from those other contexts is much more
immediate too.

This is in addition to the advantages of having a familiar and powerful
editing tool for formatting, tidying up messages, trimming unnecessary
content, etc.

I could, but wouldn't want to, live without it.

------
larve
I am a bit annoyed by all these emacs / vim / sublimetext vs. IDEs articles.
In an IDE, the editor is a small part of the overall program, and it indeed
does often suck compared to the godfathers. But it's such a small part of the
actual task of working on software that I'm ok with a few tradeoffs. On the
other hand, whoever ever tried to debug java or c++ in emacs, or even worse,
debug a single app consisting of php, ruby and javascript in emacs is going to
enter a world of pain. A task which is pretty easy to accomplish in Intellij
IDEA.

Eclipse makes it pretty easy to keep the muscle memory with its emacs+ mode,
which is quite good (it even has ido and M-x). You lose the elisp, but have a
real IDE nonetheless.

It's all about the work you need to accomplish, I find myself much more
productive with a less capable editor, but a full IDE. And I still use emacs a
lot for org-mode, editing config files, writing smaller programs. But
emulating full IDE features is just to painful (most of the time).

The only area where Emacs is actually a brilliant IDE is when using SLIME (for
Common Lisp and Clojure).

~~~
rbanffy
> But (the editor is) such a small part of the actual task of working on
> software that I'm ok with a few tradeoffs

You have to understand Eclipse and the tools most people use it with evolved
together for a long time. That creates this dependency between IDE and toolset
- it's more or less impossible to be productive in Java without an IDE. There
are, however, languages and technologies that didn't evolve together with IDEs
and employ fairly easily hand-editable files instead of overly complicated
things no human hand is supposed to touch.

Emacs' brilliance is in how it's built in itself and how one can shape it to
its needs. For instance, it took me a couple minutes to configure mine to
start with different fontsizes and screen layout in accordance to the size of
the monitor I'm using. I cannot imagine the level of insanity I would have to
go through to do it on Eclipse.

~~~
larve
What languages are these though? I switched over to eclipse for C/C++, and
these are fairly well integrated in emacs to boot. I just find it more
comfortable to write in that in eclipse, and most of the navigation and
editing commands I have in emacs work perfectly fine in eclipse with emacs+.

I moved over to intellij for java (of course), php + javascript + html (the
ability to debug php and javascript side by side is very nice), and python
(although that's one that works pretty well in emacs as well).

I guess I'm biased though because i find the navigation layout and the
autocompletion visually much nicer in editors like eclipse, whereas due to my
laziness I never configured emacs to be "visual", I still use it inside tmux
in a terminal, without graphical widgets.

That said, I'm a happy multiuser, I'm just a bit tired of the emacs over
everything, while IDEs have their own intrinsic advantages. Maybe I'm just a
discokid, but I like having to click 2 buttons to update my pom.xml rather
than going in by hand to edit the xml, or having to figure out if the maven.el
file I found somewhere is still usable.

------
4ad
I find it interesting that this class of articles has such an appeal to Hacker
News readers.

If this were an article about hammers, and how good they are for driving
nails, people wouldn't care. If this were an article about saws, and how they
are for cutting wood, people wouldn't care.

To me, the article is exactly like the examples above. Take some widely used
tool and say what it does. It's common knowledge and I don't care that you use
a particular tool exactly the way it's advertised.

Now if this were an article about using hammers for something they were not
designed for, of about using saws in creative ways, that might be interesting.
It might also be interesting to talk about what you build and how common tools
made a difference for your product.

~~~
jdietrich
Woodworking magazines are full of articles about tools and how they're used.
The most interesting pieces are invariably about how the tool changes the user
- how Japanese saws change your mental approach to jobholding, or how routers
tend to displace other tools and skills.

At a sufficiently high level, any discussion of craft inevitably becomes a
matter of philosophy. The tools in a shop tell you about how a woodworker
relates to wood; His attitudes shape his tool choices and his tools shape his
attitudes.

~~~
bergie
Yep. I spent a weekend with a group of sculptors once, and they were debating
the merits of particular drills just as eagerly as we discuss editors. Tools
matter when you use them the whole day, every day.

Though still it should be noted that most of programming is thinking, not
typing ;-)

~~~
dfc
I imagine that your sculpting friends would also note that most of sculpting
is thinking, not physichally shaping a medium.

Why do you think programming would be different?

~~~
hsmyers
Actually given the image you want to sculpt the rest of the work is 'knocking
away the parts that don't belong'. This often takes most of the time in the
overall process. There is also the matter of mounting the piece. This can take
from zero (for free standing pieces) time to significant amount of time
depending on the problem(s) involved. Overall I'd have to say that after 30+
years, doing the work takes more time than thinking up the idea. It's hard to
be exact since it depends on hard to quantify things like how you come up with
your ideas---many of mine were dreamed up while doing things like kiln watch
(someone has to be around when you are burning the wax out of molds for
casting bronze). Or when you are just sitting around with other sculptors and
bullshitting. Something gets said that leads to an idea etc. Given the way the
mind works, it would be hard to say that the thinking process starts 'NOW' and
ends 'HERE' leading to time to pick up carving tool etc. Since I long ago came
from the art department side of campus, I highly recommend taking some of
these courses not just to get those non-major credits, but to give yourself
other boxes to think in when you have to think outside the box. Must stop now,
beginning to babble :)

~~~
dfc
Are you a professional sculptor?

------
maigret
Excellent article! I agree with all points here. I think one of the most
important is "Emacs is easy to configure". You just Google a problem and copy
2 lines in your .emacs. No need to click here and there, then find out you
have to do it every time you open the editor etc.

Also one thing that has gone true in the last 15 years (but most devs seem to
still ignore it), is that emacs now has a small footprint and starts fast
compared to many IDEs.

~~~
ttt_
>> _Also one thing that has gone true in the last 15 years (but most devs seem
to still ignore it), is that emacs now has a small footprint and starts fast
compared to many IDEs._

I have started using emacs recently, coming from Eclipse, and this is the main
point that has led me to it. I use a netbook at home with only 2gb of ram, and
it absolutely takes forever to open up eclipse (even the most basic 'classic'
eclipse install), to the point where I was dreading opening it up to start
coding.

Another significant factor is that, when I started learning Scala and then
Clojure, I noticed how dependent on the tooling I had become from using
Eclipse in Java projects. For languages that do not have a mature set of tools
favoring eclipse, than you're left with a really heavy and slow text editor. I
noticed it was a terrible trade-off.

When I asked myself 'what programming environment is lightweight but goes
beyong syntx highlight?', then it came down to emacs and vi, that I heard of.
Since my particular interest was in lerning Clojure, emacs fit like a glove.

I'm still not really that productive, but in the long run I find that I'll
gain a lot more from learning to hack in emacs.

~~~
rmk2
You might also want to look into running emacs as a daemon, if you haven't
already. Since it runs as a server in the background (with a grand total of
maybe 30MB used in my case), clients pop up instantly _and_ if there were
buffers open on the server from before, they will remain open even if you
close the client's window. If you start/close emacs more often, it's
definitely a nice thing to have.

    
    
      emacs --daemon
    

clients are called using either

    
    
      emacsclient (for either terminal client or gtk/x11 client)
      emacsclient -c (to open a new frame)
      emacsclient -t (to open a frame in the current terminal)

~~~
SkyMarshal
Wow, I did not know that emacs could be run in a terminal mode like vim.
Thought it was GTK/GUI only. No excuse not to install Evil and give it a shot
now.

~~~
oscillator
emacs -nw (for "no window") is super simple.

------
theatraine
Initially I started using emacs for AUCTeX, a great extension for LaTeX. Now
it's become almost it's own OS as I can run Matlab (using Matlab mode), and
several terminals from it (using ansi-term). If you're using ansi-term, just
remember that C-c k is char mode (direct terminal entry), and C-c j is line
mode, allowing you to use the power of emacs.

~~~
disgruntledphd2
A quick question: what do you see as the advantages of ansi-term over shell
(M-x shell)?

~~~
theatraine
ansi-term in line mode is basically the same as shell, however you still have
the option of direct terminal entry with char mode, which is sometimes useful,
ie when looking at the command history of a machine you sshed to. ansi-term
can also run more programs (ie some graphical programs, man).

------
yason
I think the question for me would be why should I——or anyone for that
matter——use Eclipse or Visual Studio instead. Emacs is not an editor, it's a
keyboard language used to modify files and run programs. Further, those are
editors where extensions and settings are each a separate feature instead of a
natural flow of blended editing, reconfiguration, and extending. With Emacs,
the question is never about if some editor feature is available or if it can
be scripted together. With Emacs, the first and only question is always _How?_
as Emacs will simply turn into anything if only so told.

~~~
JustinJ70s
Anyone for that matter? How about people who find Emacs to be archaic with
weird key bindings and who don't care to spend half their time fiddling about
with lisp scripts. Don't get me wrong, it's an awesome tool and I spend a long
time using it - but it's not for everyone and bemusement at why that may be
the case is being short sighted.

------
sheckel
Aw, before I clicked through, I guessed this article was from the 90s - I was
sure that vim had taken over the world by now. Goodness gracious, folks, it's
2012!! :-)

In all seriousness, although these are all good points and I'm quite jealous
of Emacs' tetris mode, I think you're missing out on one of the best features
of Emacs: shell mode. IMO shell mode (or whatever it's called) should easily
be at the top of the list. I wish there were a decent analogue to this feature
in vim but there really isn't, just a bunch of not-quite-there plugins...

~~~
beaumartinez
How powerful is Emacs shell mode? Vim has a shell "command" (:sh), a pretty
damn crappy—well—interface to your box' shell.

~~~
disgruntledphd2
There are at least three shell modes built in (there are probably more). shell
mode (M-x shell) - gives an interface to your system shell, can handle
everything except programs like top, you can move around past commands which
is a dream. ansi-term - an actual terminal, better for top et al, can switch
between terminal mode and emacs buffer mode

eshell - shell implemented in Elisp. have never used it, but i'm sure it's
awesome.

Dired mode is also wonderful, navigate to a folder, simple one key commands to
do most of the basic shell copy/rename/move commands, with simple searching
and all the emacs shortcuts.

~~~
tbatterii
What makes eshell awesome is mostly that it blurs the lines between bash and
elisp, you sort of kind of can use them together. Unfortunately the manual
does not do this feature justice as it is largely incomplete. This article is
the best i've found.

[http://www.masteringemacs.org/articles/2010/12/13/complete-g...](http://www.masteringemacs.org/articles/2010/12/13/complete-
guide-mastering-eshell/)

And of course eshell is just a buffer so you can surf through the output with
all the available commands you typically use.

------
lflux
Why I still use emacs: I've been using it for 10+ years and my fingers and
general workflow are very very used to it. I regularly use vim (for quick
editing and vimdiff), but keep coming back.

If only emacs had a "project drawer"/"tree drawer" like textmate, then it
would be golden. ecb doesn't quite cut it for some reason, I keep reverting to
textmate each time I need to get an overview of a huge source tree I'm not
familiar with.

~~~
jeekl
Try speedbar or sr-speedbar: <http://www.emacswiki.org/emacs/SrSpeedbar>

~~~
lflux
Neither those nor emacs-nav come close to working and looking the same way the
file tree drawer in TextMate (or other IDEs) does. speedbar only shows
directories, not files, when I navigate dirs in it.

~~~
macmac
You have to enable file types in the Speedbar cf.
[http://stackoverflow.com/questions/2220005/how-do-i-
enable-S...](http://stackoverflow.com/questions/2220005/how-do-i-enable-
Speedbar-to-display-all-types-of-files) I think you will find that the
TextMate tree drawer is a toy compared to the Speedbar.

------
endlessvoid94
As a vim user, I had a bet with a coworker (emacs user): we would switch
editors for a week, with the goal of learning another tool for our daily work.
Every time one of us complained, we would pay the other $1.

I haven't switched back to vim -- that bet stopped back in November.

~~~
dnquark
One of the best things that happened to Emacs in recent years, IMO, is the
Evil project (see my blog post for an Emacs user's perspective on it:
<http://dnquark.com/blog/2012/02/emacs-evil-ecumenicalism/>) -- now you don't
have to choose between the power of Emacs an the terseness/efficiency of Vim
and modal editing. After installing Evil, I've taken to calling Emacs "my
thermonuclear editor".

------
superxor
I am an GNU Emacs user. The major problems I see are: 1> lack of Multi-
threading 2> Support for multiple major modes

The 2nd problem is the biggest I suppose. Present day development deals with
chunks of code in different languages, all put in the same file. It just kills
me to code Python+JS+HTML in a single file, pathetic support.

~~~
nO0b
What env currently supports mixed-mode editing well? They all seem pretty
crappy at the moment.

Either way, the code looks/reads a lot cleaner if you include the JavaScript
as a separate file referenced from your HTML. Solves 2 problems.

~~~
msh
Visual studio does HTML + js pretty well.

------
telent
I use emacs and have done for ~ 20 years, but I don't think this article would
sell me on it if I didn't already.

An editor is just an editor: an editor with a variety of unrelated crap (text
adventure, tetris game, mail reader) bolted on the side is not obviously
better, it might just be bloatier. The compelling feature of emacs is its
extensibility and self-documenting nature: that Gnus exists is not a big deal,
but that you could _invent_ it if it didn't already exist - that's where the
magic lies. Emacs is a habitable programming environment.

If HN lets me post links in comments, here's an example from a little while
ago showing how I once extended the Gnus email composer to check for missing
attachments -
[http://ww.telent.net/2003/1/14/_updated_for_elisp_syntax_err...](http://ww.telent.net/2003/1/14/_updated_for_elisp_syntax_error_13_01_52_gmt)

"First off, we didn’t need to restart emacs. In fact, we didn’t even need to
load any files. All of this was done on the fly. Second, we didn’t at any
point have to read an info manual, fiddle around in the filesystem, or search
a web site to get to the documentation for anything. We had a little help from
customize to tell us that ispell-message was a suitable function for this
hook, but aside from that, all we needed to know was in function and variable
docstrings."

~~~
praptak
Spot on. Adding functionality to Emacs is a matter of typing or pasting some
elisp and executing it. There exist IDEs where you need to setup and build a
project with an XML based config for this purpose :)

------
KingOfB
There's an interesting Clang autocomplete mode. It is almost great, but falls
short a bit for obj-c. If you deal with C/C++ all day, you should definitely
check it out:

<https://github.com/brianjcj/auto-complete-clang>

------
calibwam
I agree to a lot of the arguments, but for me most of them fits better to VIM.
I really have nothing against Emacs, but I just happened to start learning
VIM, and after that it's been hard to change.

In my university, there's really only some Java and Python we have to learn,
at least the first couple of years. Since I like to learn a lot of other
stuff, I kind of had to learn an editor. But most of my classmates has never
programmed outside eclipse or whatever IDE they use for python. I really don't
get how this is going to make us good computer scientist.

~~~
SkyMarshal
Here's something related, an oldie but goodie on the effects on learning
programming of editors vs ide:

<http://osteele.com/archives/2004/11/ides>

------
rmk
tramp is the best feature of emacs. Really handy when I have to edit files on
barebones systems that have only vi (not even vim) installed on them!

~~~
lowstz
Agree!

------
galactus
I "still" use emacs because of SLIME. The most pleasant programming
environment I have ever used.

------
prtamil
For common lisp development emacs SLIME is the Best for foreseeable future.

For C++ i would use QT Creator. For scripts such as shell , Python VIM is
great.

------
ulisesrmzroche
What's the fastest way to get up to speed with emacs if I'm coming from vim?

~~~
lallysingh
There's viper mode, which enables vi keybindings. A transitional technology.

You don't even have to ever turn it off!

~~~
contextfree
I once used that. I remember for extra power and/or hilarity I configured it
so that emacs commands were all available in vi "insert mode", so that Esc
effectively switched between vi and emacs.

------
tedmiston
Tetris in emacs is too good to give up. If only it had ghost pieces...

------
munchor
The writer says he thinks Emacs will evolve and get some IDE-like features,
but do you guys think Emacs will keep on evolving? Is development still active
or dead like in Vim?

~~~
sigzero
Neither Emacs nor Vim is "dead". Both are actively updated.

~~~
munchor
I use Vim, hasn't Vim 7.3 been there for ages?

~~~
MatthewPhillips
Only a couple of years ago, they increment the point version every few.

~~~
sigzero
Vim 7 added a lot of new features. Bram typical does fix releases for a while
and then there is fast and furious to the next version. Vim is definitely
still being developed.

