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.
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.
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.
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.
I think a lot of features -- especially if you want them accessible inside INSERT mode -- are accessible through CTRL+letter, no? At least omni-completion, the most useful one, used to be when I last tried it. (Has that changed? I'm not doing much editing in vim these days, so I may be wrong.)
Any command that I can think of can be mapped to work while in insertion mode.
The key however is understanding that if you are insertion mode, then key sequences start with the escape key, or, insertion commands are completed with the escape key. There is no "context switching". No more-so then having to press ctrl along with the rest of your key sequence in Emacs is "context switching".
I think "maximum extensibility" is not the philosophy of Emacs. Remember how long it took to have FFI support in Emacs (it was discussed in the article). Also, even with FFI, it is not possible to load non-free libraries. I think this shows some discrepancy from the philosophy to achieve "maximum extensibility". I would say GPL does not allow "maximum extensibility".
So the next question is: does the philosophy the author speaks of matches with the one of GPL, or rather, the one FSF and Stallman have in mind? Actually, I think these philosophies are different. If I remember correctly, in Emacs mailing list sometime ago, Stallman rejected idea of adding function to gcc to dump parse tree (or something similar) to use gcc from other software (I can't find the link right now). This was because non-free software could use gcc via CLI and "steal" the data from free software. Now, although it is the other way around, Emacs can use non-free external program. It matches with the philosophy by Matsuyama but I doubt that Stallman says it is the philosophy of Emacs.
I would say this philosophy is for author of Emacs Lisp program (though this was not what Matsuyama was talking about). You have many options. You could choose "maximum extensibility" but actually it is not doable due to GPL. You can follow FSF's philosophy (I am not sure what is it, but I believe there is). Somewhere in between, there is philosophy proposed by Matsuyama and it reflects current situation of Emacs very well, and I like it.
>the conventional wisdom that "Emacs is a good operating system, it just needs a decent text editor".
If that's the conventional wisdom, it is not particularly wise.
Emacs is much more like a Unix shell than any operating system I have ever heard of. Specifically, both Emacs and the shell fork and exec other programs a lot; a significant fraction of those programs communicate with Emacs or the shell via a PTY or a Unix pipe. In contrast, Eclipse does very little of those two things, according to the OP.
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 ) takes off.
When you get towards the bottom of the article, it actually says that this is a strength of emacs, and not a weakness.
The claim is that the weak lisp interpreter encourages work to be done in other processes (reference to the awesome Tramp), thus making the feature available to other editors (Vim, TextMate), and the shell. The author compares this philosophy to Eclipse's where everything is a Java plugin written just for Eclipse.
The claim that Emacs is dead rises from the shift in the latest versions to large included language processing plugins (JS2-Mode and Semantic) which provide rich language processing capabilities but are implemented in pure Emacs Lisp.
The author closes off by stating,
"The reason why Emacs platform is good is that it cooperates with OS, not because it is good by itself".
The awesome Tramp, is it? IMHO, of all the software on my hard drive that I use regularly, Tramp is the most likely to break or hiccup in a novel or unfathomable way.
It does fill a need or 3, I must admit, and I hate to be negative, but if that is the best example you can come up with of the positive effects of putting Emacs functionality in external programs, that makes me lean towards the conclusion that it is a bad idea to put Emacs functionality in external programs!
I agree some of them are harder to setup in Windows. But it helps (or forces) developers to make these tools and languages cross-platform, which is good, I think. And I guess making them cross-platform is actually easier than implementing them purely in Emacs Lisp.
I think you misread the philosophy he talked about. He actually thinks that having the problems about threading, libraries and low APIs is a good thing, as it helps us maximizing social value of software we develop.
He didn't say these problems are a "good thing" at all. He said externals in Emacs can be used elsewhere easily than Eclipse plugins, and that's the "good thing" (being decoupled, modular). Sometimes these problems are just a motivation, not a need, for using externals, and that's why he criticizes js2-mode and Semantic (as they're not externals). He's indeed talking about the Unix philosophy.
Python in Vim has slowly become the go-to choice to talk to an external program from Vim,
because VimScript is simply that bad.
I know little, however, about how hard ELisp makes it to interface with an external program.
The examples he gives (a JS interpreter in ELisp, and Semantic) lead me to believe
that the authors wrote all that in ELisp because it was easier than to play with an external program.
Am I wrong?
Will Guile ease the task of interfacing with an external program?
It's actually pretty easy to run external programs from elisp. stdin comes from a buffer, and stdout/stderr go to a buffer, and you can use all the usual emacs facilities on the result. See the various interactive modes (e.g., M-x run-python, M-x shell) for a demonstration.
I suspect people who write packages entirely in elisp simply like elisp. And why not? The language itself is mostly OK to use, even if it doesn't always conform to modern standards.
To be honest, ELisp is not bad. Not in the same range as VimScript. In fact, ELisp with this weird concept of I/O through buffers makes a lot of sense for a text editor and I find it quite an elegant concept (not always practical, though). And while ELisp is not really CL, the lacking parts are the interpreter and runtime themselves, not the language.
Writing elisp is not hard. What's hard is integrating all the modes, keymaps and quirky behavior of coupling all these smalls bits of code together. This is what makes emacs hard. Emacs, the "core editor" itself, is incredibly small. Way smaller than vim (build it by hand if you don't believe it). Emacs as the editor that you use every day is almost pure extensions.
There's a /whole lot/ of global state in an editor. This is not going to change with Python, Guile or any other language. Users that complain about ELisp, most of the time actually never tried to write ELisp at all (they just glue some elisp around in .emacsrc). That's fine, but they don't realize what's going on under the hood. The C/C++ mode in emacs is completely different to the "stupid" syntax highlighting in Vim or most other editors.
I normally recommend switching to another editor if after several years you still don't appreciate the difference. IMHO emacs, as it is, is a great editor. ELisp is part of the success (though guile would be a step forward).
I'm not sure about you, but the level of effort required to keep my emacs.d up to date and the level of effort required for each project has turned me away from emacs as my main development environment.
What are you doing with emacs.d that requires a burdensome level of effort to keep it "up to date"? What does that even mean? I've been using Emacs almost 10 years, and I very infrequently modify my emacs.d, and I don't know many people who do. Sure, I could spend a lot of time tweaking it and messing around with it, but it'd be an entirely self inflicted thing, and not the fault of Emacs. I could spend all day fiddling with .vimrc, or the Visual Studio settings, too.
I also don't understand the what you mean by "the level of effort required for each project" in the context of Emacs. What "project"s are you talking about?
How much effort do you have to put in to keep your .emacs.d up to date ?
I only started using emacs in emacs 22, so I haven't had to keep things working for 5-10 major releases like I'm sure some people have, but my init.el and .emacs.d have been pretty static the whole time.
Do you follow @melpa_emacs on twitter? Packages are not static by a loooooong shot. I am mainly interested in using emacs for Python, Org-mode, JS, HTML. In terms of years of use, I am on year three or so... but I like to keep my shit on lock. My biggest mistake was trying Pycharm. Now I constantly compare Emacs to Pycharm... and it just doesn't compare.
I build my emacs from trunk every ~1-3 months for No Good Reason (tm), and I scarcely ever have anything in my own configuration (init.el, custom.el, various random things I've installed in ~/.emacs.d) break.
(I also edit python in emacs regularly, not sure what's changed in the last N years)
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?
Back in 2002, the better choice was Common Lisp. One of CLISP's authors even made it work with Emacs over the course of a week-end .
There's never going to be the perfect fit for an embedded extension language. Hey, wasn't that what Lua wanted to be, and Tcl before it?
Guile certainly isn't the easiest fit, but it's the only one that will get accepted.
At least, if they slowly change the actual extension language away from ELisp, all extensions that rely on external programs will survive better.
Guile is a very capable Scheme implementation that was made to be the official GNU extension language. It features a very nice C API and FFI. Racket and Guile have different design goals. Guile fits Emacs' edit-the-editor-while-you-edit paradigm better.
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  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'  (it interfaces with the C++ code by simply importing the prebuilt ycm_core.so ). There is still no widely-used well-maintained clang completer for Emacs; the most dominant one spawns clang for everything .
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 , but clearly not enough has been done about it.
On the other hand, the only usable Intellisense engines or debugger integrations I tried have been built for Emacs and not Vim. This is mostly because, by design, offloading tasks to other processes without blocking the gui-thread is easier to do in Emacs. Also Vim really needs good integration with other languages such as Python, because Vimscript is simply awful.
There are problems with Emacs. First, Elisp is kind of an outdated and dirty Lisp dialect. It's kind of neat for extending Emacs, but it's also a poor Lisp dialect by modern standards. I would love an alternative to Emacs built on top of Scheme, with its awesome continuations support, or on top of Clojure.
The other problem I'm seeing is that Emacs, as awesome as it may be, is also outdated in what it can do. Smalltalk set a high bar long ago in what IDEs can do and Smalltalk IDEs still haven't been surpassed in terms of experimental development that people tend to do in REPLs nowadays. Having something like a Smalltalk IDE, that uses realtime feedback and visuals to aid in learning, discovery or debugging, with the same philosophy of Emacs (e.g. open-source, totally customizable, turtles all the way down, transcending languages or operating-systems, etc...) would be priceless.
This is why I have high hopes for Light Table , hopefully it will bear fruits as planned by its author.
Yeah, the difference is that this one spawns a prebuilt clang-complete  (a more lightweight program) instead of clang. Still, nowhere as good as using a prebuilt ycm_core.so directly. Thanks for the pointer nevertheless.
> 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.
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...
> 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.
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.
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!
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.
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.
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.
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.
While Python scripting in Vim is very cool, my understanding was that Vim's scripting API was rather limited in comparison to Emacs. Vim only exposes a few hooks with the majority of the editor features implemented in its C core, while Emacs implements pretty much everything in Elisp, thus exposing pretty much everything to extensions.
But please correct me if I'm wrong -- this is just my impression from reading HN etc.
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.
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.
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.
Evil is awesome, drastically reduces the chances of emacs pinky. To get a not-very-close, but good-enough to halfway-comparable setup of say Pycharm: Projectile/Helm for project management, Jedi.el, Use magit for git, virtualenv.el, nxhtml/mumamo for web stuff, snippet.el... then make sure you have pip installed jedi and python-epc. Then figure out how to use them. Ie. Activate the virtualenv inside emacs and go from there.
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.
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).
>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.
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.
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.
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
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"  expressed my nascent thoughts exactly), I think he would qualify for "eccentric." I bet he'd even like the term :)
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).
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.