
Emacs is Dead (2010) - tkf
http://tkf.github.io/2013/06/04/Emacs-is-dead.html
======
bitwize
This article's "philosophy of Emacs" runs counter to the conventional wisdom
that "Emacs is a good operating system, it just needs a decent text editor".
If anything what the author describes is a "philosophy of Acme" -- do as much
as possible by piping in and out of external processes. While Emacs can do
this, there is no guiding principle to favor it over elisp extensions.

I think the philosophy of Emacs, if it has one, is "maximum extensibility".
Whether that be with elisp or external processes matters not.

EDIT: forgot the word "conventional" :)

~~~
joshAg
> the wisdom that "Emacs is a good operating system, it just needs a decent
> text editor".

that's not wisdom; that's a sarcastic quip by the vim side of the emacs-
vim/vim-emacs religious war.

~~~
evincarofautumn
It might be a joke, but it’s quite true. Vim is an excellent and efficient
text editor, and Vim users consequently tend to see Emacs as a powerful but
massively inefficient text editor. Which of course it is, but it’s also a
massively _efficient_ keyboard interface to an interactive text-based Lisp
environment. If you’re just using Emacs to edit text, you’re missing out.

~~~
rat87
These days many users of vim tend to use many plugins making it in some ways a
lot like emacs. Also emacs isn't particularly inefficient on modern machines
other then problems with the ui and single threading which I believe vim
shares.

~~~
evincarofautumn
I meant human efficiency, not the computer kind.

~~~
Ma8ee
In what way is Emacs inefficient for humans?

~~~
regularfry
Try this task for an example: underline an arbitrary line of text with '='
characters. In vim that's 11 keypresses across 3 operations, possibly less if
there's a shortcut I haven't thought of. How many keypresses does emacs take
out of the box?

Emacs, especially with paredit, is fairly well optimised for editing
s-expressions and the like. Vim is _very_ well optimised for line-based
editing, but I don't get on with its buffer management at all.

~~~
intractable

        > underline an arbitrary line of text with '=' characters. In vim that's 11 keypresses across 3 operations
    

Sounds like a vimgolf challenge to me. Here's my entry:

YpVr=

~~~
swah
I'm wondering now that the creativity to come up with those things might
actually be beneficial to coding.

~~~
danielbarla
I'd agree with that, and also - an intense dislike of unnecessary repetition /
work is definitely a good thing. I'm not sure using Vim causes that, but it
definitely reinforces it.

For those that are interested, I would recommend "Practical Vim", and it
includes many examples (including the above one) which really accelerate the
learning process:

<http://pragprog.com/book/dnvim/practical-vim>

There are definitely cheaper alternatives (including free ones), but this book
really laid the concepts out very clearly for me.

------
p4bl0
I don't believe that Emacs is dead at all. Actually, most of the problems
(multithreading, libraries, file I/O) raised by this article can be solved by
replacing Emacs Lisp backend with Guile, which is an active and promising
project [1,2]. As for Emacs philosophy, it might even survive Emacs (in the
hypothetical situation where Emacs dies) if a project such as Emacsy (the
second one presented in [1]) takes off.

[1] [https://lists.gnu.org/archive/html/guile-
user/2013-05/msg000...](https://lists.gnu.org/archive/html/guile-
user/2013-05/msg00081.html)

[2] [https://www.google-
melange.com/gsoc/proposal/review/google/g...](https://www.google-
melange.com/gsoc/proposal/review/google/gsoc2013/bpt/35002)

~~~
TylerE
Why guile, which has exactly zero usage outside a few GNUtoys.

Why not, e.g. Racket? If you're going to go the trouble, _get it right_.

~~~
nahreally
Because it's been years in the works, it's finally about ready, and Racket
only now is in everyone's mouths? Guile is now also able to run other
languages as well, like Javascript, or at least so their maintainers claim.

Besides, I know that among users of fringe languages like us (you too are, I
presume) this is a bit of a taboo question... but who uses Racket so much as
for it to make a difference here?

~~~
TylerE
Racket (Formally PLT Scheme) has been the dominant scheme for serious use for
years. It's not "the n3w hawtness" by any means, but the established leader.

------
jamii
I have a lot of hope for Light Table as a modern emacs-like runtime. I look
forward to the day when extending my editor doesn't make me sad inside.

~~~
artagnon
I would have some hope if it were an open source project, and I were able to
read the code.

~~~
Makkhdyn
It seems that it will be

> I'm a firm believer in open source software and open source technologies. I
> can guarantee you that Light Table will be built on top of the technologies
> that are freely available to us today. As such, I believe it only fair that
> the core of Light Table be open sourced once it is launched. At some level,
> this is an experiment in how open source and business can mix - it will be
> educational for us all.

Source: <http://www.kickstarter.com/projects/ibdknox/light-table>

------
jzelinskie
This is actually really interesting from a vim user's perspective. We've long
sought after an extension language as good as emacs lisp and finally now have
gotten the news that vim plans to eventually phase out vimscript in favor of
Python. The future looks good!

~~~
tmhedberg
I think you have misinterpreted something. There have been a lot of Vim
patches recently that are dramatically improving the long-existing Python
scripting support in preparation for the upcoming Vim 7.4 release. But Bram
has not said anything about "phasing out" VimScript. The two languages will
continue to coexist (along with the handful of others that are also
supported). There is far too much investment in VimScript, however flawed it
may be, to actually deprecate or remove it.

~~~
jzelinskie
It is very likely that during the hype I had misinterpreted the 7.4 plans. I
was under the impression that the work on Python was trying to make it the
dominant means of extending vim while keeping vimscript for legacy reasons. I
mean this is still technically feasible, but would require the support of the
whole vim community. I would go on about how it's weird that many vim users
aren't familar vimscript, but I'd feel like I'm preaching to the choir. Thanks
for clearing things up.

~~~
goldfeld
I'm reaching a point where I can consider myself at home with VimScript
(moreso the bigger investment has been on the built-in vim functions and not
on the language proper), and I'm becoming increasingly active within the Vim
community. I can tell I don't have any plugins in Python/Ruby and actively
avoid them, seeking lightweight alternatives instead, and I would detach
myself from the community if VimScript were to be phased out in favor of
Python (don't have too much love for it.) Fortunately none of that is going to
happen.

~~~
jzelinskie
I do often opt for the slower, pure vimscript extensions in order to avoid
having to remember to compile specific ones. Hypothetically, if vim had an
embedded form of Lua, it could satisfy the people who want a familiar
scripting language and it wouldn't be dependent on whatever version of the
language the system has installed. I think that would be a excellent choice if
you were writing a brand new editor.

To be perfectly honest, I think so many vim users (including myself) don't
know vimscript [in depth] because they can easily find everything they need
already.

------
quotemstr
That's funny: for a dead project, there's an awful lot of traffic on emacs-
devel, a big user community, lots of interesting new projects (like org-mode),
and an amazing amount of utility.

If this is what a dead project looks like, the living really ought to envy the
dead.

~~~
ajross
The title is linkbait, but I think (as a two-decade emacs user, mind you) that
the technical points are actually pretty sound. Emacs absolutely _is_ crufty
when you try to stretch it beyond its original paradigm. Elisp, as an
environment, is woefully primitive compared to the kind of elegance and
integration you can achieve with more modern languages. The example of code
completion is actually pretty informative -- this is something that IDEs were
doing routinely 15 years ago that emacs still doesn't do well, or in many
cases at all (for languages other than elisp, of course).

Now, that doesn't outweight the good, and I still use it, and probably will
until I die. But I think if you want to be honest about things you need to
think seriously about what emacs would look like if you "started from scratch"
with the same philosophy but with modern goals. Probably not like Eclipse for
sure, nor even Sublime. But it probably wouldn't look much like GNU Emacs
either...

~~~
irahul
> The example of code completion is actually pretty informative -- this is
> something that IDEs were doing routinely 15 years ago that emacs still
> doesn't do well,

Isn't the point of the article that emacs shouldn't do it but call upon
something which does? I use gocode for go completion in vim. gocode has
support for a number of editors and there are instructions to make it work
with editors which aren't supported out of the box. That is what the article
advocates(and I agree) - use emacs/vimscript for glue code, not for
implementing interpreters or completers.

~~~
ajross
Sure. But even then you're stuck with using elisp as an extension language
(though frankly vimscript isn't much better), and relative to other tools
(perl, say) elisp kind of sucks as a tool integration language. To get to what
I was saying earlier, if you were to design an editor able to easily integrate
(for example) third party syntax highlighting and code completion plugins for
arbitrary languages, it wouldn't look like GNU emacs.

Again, to be clear: I use emacs every hour of every day. I used it to type
this post. I'm not giving it up any time soon. But it's important not to
delude ourselves about its shortcomings.

------
LowKarmaAccount
The article is extremely poorly translated, and many of the sentences don't
make sense. This makes it hard for me to figure out if something was lost in
translation or if the author is as ignorant as the translation makes him out
to be.

I won't go through the post line by line; I think this paragraph sufficiently
establishes that the author is ignorant.

> The virtue of Unix convention of making a big thing by combining small
> things is inherited in Emacs. This virtue itself is the reason why I am
> using Emacs. However, this may be becoming history. What is the meaning of
> the world without the virtue or philosophy, but with only benefit? I’d be
> disappointed if Emacs become so.

The precursors of Emacs were written at the AI lab at MIT, which at the time
ran the ITS operating system. ITS had values that were pretty much orthogonal
to Unix, which makes the statement especially ignorant. GNU Emacs's first
public release in the 80s had to be ported to Unix to make it work.

Emacs is famous for being very extensible and can be used as a web browser,
newsreader, spreadsheet, etc. You can do almost anything and never leave the
Emacs environment. This is the opposite of combining many small programs to
create something big.

Emacs also has a clear and logical design, and allows you redefine almost
anything you don't like. Unix is famous for having a horrendous, incoherent
design that is so poor that many of its commands are digestive noises (nroff,
fsck, awk, grep). Its other commands are cryptically named and for years and
years the documentation was nonexistent or terrible.

------
artagnon
Although this article was written in 2010, his general complaint still
applies. Compare a code-completion engine written for Emacs, with that written
for Vim: auto-complete [1] is written completely in Elisp and utilizes
Semantic as a source (mentioned in the article; also full Elisp), while a
completion engine for Vim can be written in C++/ Python: Python is first-
class, and it's a simple matter of invoking 'py import vim' [2] (it interfaces
with the C++ code by simply importing the prebuilt ycm_core.so [3]). There is
still no widely-used well-maintained clang completer for Emacs; the most
dominant one spawns clang for everything [4].

That said, Emacs has a very rich Elisp ecosystem that's not going away anytime
soon. By focusing on extensibility from the very beginning, Emacs has done
many things right (it's just an Elisp interpreter with some editor functions
bundled in); in comparison, Vim is a dumb-text editor focusing on keybindings,
with extensibility as an afterthought. I don't think it is possible to replace
Emacs today, primarily because writing a truly extensible text editor is a
huge project with many boring parts, and there is no money to be made as a
result. Elisp does have its drawbacks, and the Emacs community is suffering
because of "philosophical" decisions like bzr (a dead project), instead of
focusing on technical merit. So, the project will die a slow painful death,
but I don't think that's happening anytime soon.

The takeaway is that Elisp needs to learn to interface with other languages
better. There is a dead Elisp <-> Ruby bridge [5], but clearly not enough has
been done about it.

[1]: <https://github.com/auto-complete/auto-complete>

[2]:
[https://github.com/Valloric/YouCompleteMe/blob/master/autolo...](https://github.com/Valloric/YouCompleteMe/blob/master/autoload/youcompleteme.vim#L41)

[3]:
[https://github.com/Valloric/YouCompleteMe/blob/master/cpp/yc...](https://github.com/Valloric/YouCompleteMe/blob/master/cpp/ycm/CMakeLists.txt#L20)

[4]: [https://github.com/brianjcj/auto-complete-
clang/blob/master/...](https://github.com/brianjcj/auto-complete-
clang/blob/master/auto-complete-clang.el#L156)

[5]: <https://github.com/trogdoro/trogdoro-el4r>

~~~
sa1
I use this async version[1] for completion, it doesn't spawn clang everytime.

[1]: <https://github.com/Golevka/emacs-clang-complete-async>

~~~
artagnon
Yeah, the difference is that this one spawns a prebuilt clang-complete [1] (a
more lightweight program) instead of clang. Still, nowhere as good as using a
prebuilt ycm_core.so directly. Thanks for the pointer nevertheless.

[1]: [https://github.com/Golevka/emacs-clang-complete-
async/blob/m...](https://github.com/Golevka/emacs-clang-complete-
async/blob/master/auto-complete-clang-async.el#L43)

~~~
sa1
The clang-complete is also a running process and gets spawned just once.

------
monkmartinez
TKF is an awesome (world class?) python and emacs/elisp developer. His
projects have helped tune my emacs into a decently powerful python development
vehicle. However, the level of effort required to get the basic functionality
of a modern IDE like Pycharm has been daunting and required hours upon hours
of fiddling.

~~~
erikcw
Will you post links to some of these packages? I'm building up my Emacs Python
toolkit after many years of being a Vim user (with liberal use of Evil mode of
course! :-)

~~~
camperman
My favorite of TKF's packages is auto-complete: <https://github.com/auto-
complete/auto-complete>

It's an elegant and very powerful extension of the built-in completion that
works particularly well on reallyStupidlyLongMethodNames in programming
languages - especially handy in conjunction with tags and cscope if you're
jumping around a large codebase. Dunno if it plays well with Evil mode though.

~~~
kindahero
Actually, auto-complete was written by Matsuyama (original author this
article), though tkf has contributed to the project.

------
jongraehl
re: the social value of emacs-lisp parsers/code-completion etc, perhaps
someone could supply an API where other programs can query a headless emacs
runtime. I defer to the author's experience when he says that emacs is a poor
runtime for simultaneous editing + compute, but perhaps it's acceptable for
compute-only (and this separate-process approach could in theory improve
interactivity for the emacs editor as well).

My emacs at times can't keep up with my typing. But I love what it does for
me. The lack of threading is a huge headache for elisp developers - they have
to resort to manual cooperative-task-slicing hacks.

~~~
npsimons
_perhaps someone could supply an API where other programs can query a headless
emacs runtime_

It's called emacsclient; I'm currently using it to send links to org-mode from
Firefox.

 _I defer to the author's experience when he says that emacs is a poor runtime
for simultaneous editing + compute,_

I can back this up. I love emacs to death, but the singlethreadedness is such
a pain. Especially if you are on a platform that's a little slow (say,
Cygwin), and waiting for freaking file I/O or just a blocking external process
(when you're trying to run two or three or more).

~~~
hollerith
>I love emacs to death, but the singlethreadedness is such a pain. Especially
if . . . or just a blocking external process (when you're trying to run two or
three or more).

I am having trouble imagining how you end up in a situation where Emacs is
waiting on a blocking external process while trying to run other external
processes.

There two kinds of external processes inferior to Emacs: those that
communicate with Emacs synchronously and those that communicate
asynchronously.

The inferior shell process in a shell-mode buffer is probably the most
familiar example of the latter. (Any mode derived from comint mode is an
example.) Your Emacs is never waiting for an asynchronously-communicating
external process, is it?

The prototypical example of a process that communicates with Emacs
synchronously is when Dired forks and execs the ls command to get a directory
listing. I never find myself waiting for this ls command. The only external
process I notice myself ever waiting for is the movemail program distributed
with Emacs -- and that never took more than around 10 seconds (and usually a
lot less) even on early-1990-vintage computers like a 386. So I am having
trouble imagining what your "when you're trying to run two or three or more
[external processes]" refers to.

Parenthetically, I could eliminate the delays caused by movemail by rewriting
vm-get-new-mail to use async io when it is finished like M-x man uses. Adding
threads to Emacs would not be necessary.

But then I have very little experience of or knowledge Windows. Is this
waiting you refer to a Windows-only thing?

The OP maintains that it is probably a good thing that Emacs is not multi-
threaded, and after 20 years of using Emacs and hacking on Emacs I tend to
agree -- but my experience is almost all on Unix-like systems.

------
why-el
This should have been titled "The death of the Emacs Philosophy", although I
am not sure what that is exactly. Emacs will hang on for a litte while.

~~~
tkf
I agree with you that the title is a bit misleading and trolling. And I
actually name it like you do if I were him. I just translated it directly.

------
eksith
The biggest problem being Emacs isn't just a text editor. If it were, most if
not all of these problems would have been resolved already. It's _very_ hard
to make repairs to a working bridge while in service and carrying rush-hour
traffic. There's just so much predictability counted on by everyone who uses
it, there are really no simple solutions.

I have to say though, external module(s) may be the way to go about it.

For the curious :

<http://www.emacswiki.org/emacs/TrampMode>

------
PuercoPop
Speaking of Steve Yegge he is currently writing an 'ide as a service'. He
recounts people has accused him of having the hidden agenda of advancing the
cause of emacs. I think he would agree with m2ym's assessment of the
philosophy of Emacs

------
michaelwww
"js2-mode is developed by an eccentric developer called Steve Yegge"

I think the translator didn't get it right when he/she called Steve Yegge
"Eccentric." Google translate makes no mention of this, while Bing describes
js2-mode as "unusual, which makes more sense:

"js2-mode new JavaScript for measure mode made by Developer Steve Yegge is
somewhat unusual, as implemented in Emacs Lisp"

~~~
tkf
Well, I am Japanese and I am almost sure my translation is right. But I hope
calling the s/he "Eccentric" is not very rude. I just thought it is better
than "unusual"... or not?

Ah, I just notice "unique" fits the context very well. Perhaps I will change
that later.

~~~
prewett
I personally think that "eccentric" is more polite than "unusual," which could
be either positive or negative. It's also better than "unique"; I mean,
everyone is unique... Given Steve Yegge's hilarious, insightful, and somewhat
cheeky rants (after learning Java for a few months, "Kingdom of Nouns" [1]
expressed my nascent thoughts exactly), I think he would qualify for
"eccentric." I bet he'd even like the term :)

[1] [http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

~~~
tkf
Thanks for the explanation. It is hard feel this kind of nuance as my English
is not that good. It's also good to know that he'd like that :)

------
leif
Regarding "no multi-threading support", I have often wished for a node.js-like
abstraction for event-driven processing in elisp. Seems like it could take the
pain out of writing modules that want to do interesting processing or network-
heavy stuff (looking at you, CEDET over TRAMP).

------
lowglow
Techendo has a good emacs tutorial for anyone looking:
[http://www.techendo.co/posts/techendo-tutorial-emacs-with-
ti...](http://www.techendo.co/posts/techendo-tutorial-emacs-with-tim-jarratt)

------
solomatov
Emacs, is obsolete but not for the reasons described in the article. I think
the main problem is lack of smart IDE support. We can't easily define a
language, a parser for it, reference resolve rules, analyze code, navigate
reference, provide completion, etc. These features, not editors with a good
text manipulation facilities get you the largest performance gain today.

Take a look where sublime, or IntelliJ is heading to. IntelliJ, for example,
has a toolkit for quickly defining support for languages:
<https://github.com/JetBrains/Grammar-Kit>

~~~
swah
I don't think Sublime is heading the ways of IDEs.. why do you think so?

~~~
solomatov
What do you mean by IDE? For me, IDE, is just an editor with some good
integrations with tools I use.

~~~
swah
Yes, but I haven't seen any great Sublime extensions yet - there isn't even a
good Git integration.

~~~
solomatov
I use sublime mainly for Haskell development. Haskell sublime is the best
editor support for Haskell.

------
microcolonel
Emacs has been ported(I run it normally and haven't witnessed any issues) to
GNU Guile. I assume that you could extend emacs with scheme, javascript, and
soon lua.

Go have fun.

------
tree_of_item
This is a very good point. Check out <http://vimeo.com/39938276>, a video
about Ensime, a Scala/Java IDE as an external process. Daniel Spiewak makes
largely the same point as this article: interprocess communication provides
much better reusability than baking things in to a single process, whether
that be Emacs or Eclipse.

bitwize makes another good point: this is less the "philosophy of Emacs", and
more the philosophy of Unix (or perhaps, more specifically, Acme). It's ironic
that some of the best parts of Emacs are the ones that look less like a Lisp
Machine and more like a Unix pipeline, but there it is.

------
serge2k
So "<insert popular product here> is dead" blogs are popular in Japan too?

