16 ms·

Emacs is Dead (2010)

144 points by tkf 13y ago

jongraehl 13y ago
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.
- kindahero 13y ago
  > My emacs at times can't keep up with my typing. But I love what it does for me. Try to set debugger on (M-x toggle-debug-on-quit) and when emacs stops responding press C-g to get to know what was emacs doing.
- npsimons 13y ago
  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 13y ago
    >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.
eksith 13y ago
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 http://www.emacswiki.org/emacs/TrampMode
- deleted 13y ago
  [deleted]
jzelinskie 13y ago
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!
- why-el 13y ago
  Really? That would be cool. Can you point me to a thread or something where I can read about these developments?
  - hexd 13y ago
    For vim scripting with Python: http://www.tummy.com/presentations/vimpython-20070225/ http://www.tummy.com/presentations/vimpython-20070225/
- pekk 13y ago
  As a vim user it doesn't make sense that you didn't already know vim was scriptable with multiple other languages (e.g. perl, ruby, tcl, python ...) already for a long time. As a vim user, emacs lisp is bad. A proper lisp would be more worthwhile.
- tmhedberg 13y ago
  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 13y ago
    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.
p4bl0 13y ago
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/msg00081.html https://lists.gnu.org/archive/html/guile-user/2013-05/msg000... [2] https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/bpt/35002 https://www.google-melange.com/gsoc/proposal/review/google/g...
- tkf 13y ago
  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.
  - hexd 13y ago
    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.
  - espadrine 13y ago
    Guile integration may matter, assuming it happens (not everybody seems happy: https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00291.html https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00...) 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?
why-el 13y ago
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 13y ago
  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.
jamii 13y ago
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 13y ago
  I would have some hope if it were an open source project, and I were able to read the code.
  - Makkhdyn 13y ago
    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 http://www.kickstarter.com/projects/ibdknox/light-table
bitwize 13y ago
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 13y ago
  > 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.
  - bitwize 13y ago
    Sorry, I meant to say "conventional wisdom".
    - vvhn 13y ago
      eh ? like your parent comment pointed out - it's a quip by us vi users, not "wisdom" (conventional or otherwise) :-)
  - evincarofautumn 13y ago
    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 13y ago
      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.
leif 13y ago
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).
michaelwww 13y ago
"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 13y ago
  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.
  - michaelwww 13y ago
    Richard Stallman is a true eccentric. Steve Yegge has called himself "The drunken blogger," which is unusual, but he seems pretty normal otherwise. Just outspoken. No, I don't think it is rude to call him unusual, it still feels like you were trying to say JavaScript in Emacs was unusual and not Steve Yegge, but I'll take your word for it.
  - prewett 13y ago
    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-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
    - tkf 13y ago
      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 :)
serge2k 13y ago
So "<insert popular product here> is dead" blogs are popular in Japan too?
monkmartinez 13y ago
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 13y ago
  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 13y ago
    My favorite of TKF's packages is auto-complete: https://github.com/auto-complete/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 13y ago
      Actually, auto-complete was written by Matsuyama (original author this article), though tkf has contributed to the project.
  - kindahero 13y ago
    checkout http://tkf.github.io/emacs-jedi/ http://tkf.github.io/emacs-jedi/
  - monkmartinez 13y ago
    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.
LowKarmaAccount 13y ago
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.
- deleted 13y ago
  [deleted]
tree_of_item 13y ago
This is a very good point. Check out http://vimeo.com/39938276 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.
quotemstr 13y ago
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 13y ago
  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 13y ago
    > 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 13y ago
      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.
PuercoPop 13y ago
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
lowglow 13y ago
Techendo has a good emacs tutorial for anyone looking: http://www.techendo.co/posts/techendo-tutorial-emacs-with-tim-jarratt http://www.techendo.co/posts/techendo-tutorial-emacs-with-ti...
microcolonel 13y ago
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.
artagnon 13y ago
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 https://github.com/auto-complete/auto-complete [2]: https://github.com/Valloric/YouCompleteMe/blob/master/autoload/youcompleteme.vim#L41 https://github.com/Valloric/YouCompleteMe/blob/master/autolo... [3]: https://github.com/Valloric/YouCompleteMe/blob/master/cpp/ycm/CMakeLists.txt#L20 https://github.com/Valloric/YouCompleteMe/blob/master/cpp/yc... [4]: https://github.com/brianjcj/auto-complete-clang/blob/master/auto-complete-clang.el#L156 https://github.com/brianjcj/auto-complete-clang/blob/master/... [5]: https://github.com/trogdoro/trogdoro-el4r https://github.com/trogdoro/trogdoro-el4r
- sa1 13y ago
  I use this async version[1] for completion, it doesn't spawn clang everytime. [1]: https://github.com/Golevka/emacs-clang-complete-async https://github.com/Golevka/emacs-clang-complete-async
solomatov 13y ago
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 https://github.com/JetBrains/Grammar-Kit
- swah 13y ago
  I don't think Sublime is heading the ways of IDEs.. why do you think so?
  - solomatov 13y ago
    What do you mean by IDE? For me, IDE, is just an editor with some good integrations with tools I use.
    - swah 13y ago
      Yes, but I haven't seen any great Sublime extensions yet - there isn't even a good Git integration.
      - solomatov 13y ago
        I use sublime mainly for Haskell development. Haskell sublime is the best editor support for Haskell.
kaffiene 13y ago
I know this will immediately mark me as a heretic, but I am a long time and current Emacs user, so this comes from a place of love, really :o) -- I believe the best thing for Emacs would be to be rewritten in Clojure with Clojure as the scripting language. This would: * Maintain the Lisp culture * Speed up the whole enterprise * Allow multithreading * Remove the need for most external programs * Work across platforms (many Emacs extensions or programs rely on Unix commands which don't come with Emacs) * Provide the ability to apply a decent UI - not that I have any on my Emacs - I turn the toolbar off, but dialogs for projects / browsers could be better (read: "not suck") * Would allow the ability to immediately get a bunch of proper language parsers like Yegge's JS mode - all the ANTLR parsers are immediately available to use in Clojure and would give emacs the language-aware goodness that Eclipse and Netbeans have. OK shoot me now, but I think it would be awesome :o)

144 points by tkf 13y ago

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.

kindahero 13y ago
> My emacs at times can't keep up with my typing. But I love what it does for me. Try to set debugger on (M-x toggle-debug-on-quit) and when emacs stops responding press C-g to get to know what was emacs doing.
npsimons 13y ago
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 13y ago
  >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.

eksith 13y ago

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 http://www.emacswiki.org/emacs/TrampMode

deleted 13y ago
[deleted]

jzelinskie 13y ago

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!

why-el 13y ago
Really? That would be cool. Can you point me to a thread or something where I can read about these developments?
- hexd 13y ago
  For vim scripting with Python: http://www.tummy.com/presentations/vimpython-20070225/ http://www.tummy.com/presentations/vimpython-20070225/
pekk 13y ago
As a vim user it doesn't make sense that you didn't already know vim was scriptable with multiple other languages (e.g. perl, ruby, tcl, python ...) already for a long time. As a vim user, emacs lisp is bad. A proper lisp would be more worthwhile.
tmhedberg 13y ago
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 13y ago
  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.

p4bl0 13y ago

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/msg00081.html https://lists.gnu.org/archive/html/guile-user/2013-05/msg000... [2] https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/bpt/35002 https://www.google-melange.com/gsoc/proposal/review/google/g...

tkf 13y ago
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.
- hexd 13y ago
  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.
- espadrine 13y ago
  Guile integration may matter, assuming it happens (not everybody seems happy: https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00291.html https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00...) 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?

why-el 13y ago

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 13y ago
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.

jamii 13y ago

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 13y ago
I would have some hope if it were an open source project, and I were able to read the code.
- Makkhdyn 13y ago
  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 http://www.kickstarter.com/projects/ibdknox/light-table

bitwize 13y ago

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 13y ago
> 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.
- bitwize 13y ago
  Sorry, I meant to say "conventional wisdom".
  - vvhn 13y ago
    eh ? like your parent comment pointed out - it's a quip by us vi users, not "wisdom" (conventional or otherwise) :-)
- evincarofautumn 13y ago
  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 13y ago
    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.

leif 13y ago

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).

michaelwww 13y ago

"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 13y ago
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.
- michaelwww 13y ago
  Richard Stallman is a true eccentric. Steve Yegge has called himself "The drunken blogger," which is unusual, but he seems pretty normal otherwise. Just outspoken. No, I don't think it is rude to call him unusual, it still feels like you were trying to say JavaScript in Emacs was unusual and not Steve Yegge, but I'll take your word for it.
- prewett 13y ago
  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-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
  - tkf 13y ago
    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 :)

serge2k 13y ago

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

monkmartinez 13y ago

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 13y ago
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 13y ago
  My favorite of TKF's packages is auto-complete: https://github.com/auto-complete/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 13y ago
    Actually, auto-complete was written by Matsuyama (original author this article), though tkf has contributed to the project.
- kindahero 13y ago
  checkout http://tkf.github.io/emacs-jedi/ http://tkf.github.io/emacs-jedi/
- monkmartinez 13y ago
  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.

LowKarmaAccount 13y ago

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.

deleted 13y ago
[deleted]

tree_of_item 13y ago

This is a very good point. Check out http://vimeo.com/39938276 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.

quotemstr 13y ago

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 13y ago
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 13y ago
  > 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 13y ago
    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.

PuercoPop 13y ago

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

lowglow 13y ago

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

microcolonel 13y ago

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.

artagnon 13y ago

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 https://github.com/auto-complete/auto-complete [2]: https://github.com/Valloric/YouCompleteMe/blob/master/autoload/youcompleteme.vim#L41 https://github.com/Valloric/YouCompleteMe/blob/master/autolo... [3]: https://github.com/Valloric/YouCompleteMe/blob/master/cpp/ycm/CMakeLists.txt#L20 https://github.com/Valloric/YouCompleteMe/blob/master/cpp/yc... [4]: https://github.com/brianjcj/auto-complete-clang/blob/master/auto-complete-clang.el#L156 https://github.com/brianjcj/auto-complete-clang/blob/master/... [5]: https://github.com/trogdoro/trogdoro-el4r https://github.com/trogdoro/trogdoro-el4r

sa1 13y ago
I use this async version[1] for completion, it doesn't spawn clang everytime. [1]: https://github.com/Golevka/emacs-clang-complete-async https://github.com/Golevka/emacs-clang-complete-async

solomatov 13y ago

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 https://github.com/JetBrains/Grammar-Kit

swah 13y ago
I don't think Sublime is heading the ways of IDEs.. why do you think so?
- solomatov 13y ago
  What do you mean by IDE? For me, IDE, is just an editor with some good integrations with tools I use.
  - swah 13y ago
    Yes, but I haven't seen any great Sublime extensions yet - there isn't even a good Git integration.
    - solomatov 13y ago
      I use sublime mainly for Haskell development. Haskell sublime is the best editor support for Haskell.

kaffiene 13y ago

I know this will immediately mark me as a heretic, but I am a long time and current Emacs user, so this comes from a place of love, really :o) -- I believe the best thing for Emacs would be to be rewritten in Clojure with Clojure as the scripting language. This would: * Maintain the Lisp culture * Speed up the whole enterprise * Allow multithreading * Remove the need for most external programs * Work across platforms (many Emacs extensions or programs rely on Unix commands which don't come with Emacs) * Provide the ability to apply a decent UI - not that I have any on my Emacs - I turn the toolbar off, but dialogs for projects / browsers could be better (read: "not suck") * Would allow the ability to immediately get a bunch of proper language parsers like Yegge's JS mode - all the ANTLR parsers are immediately available to use in Clojure and would give emacs the language-aware goodness that Eclipse and Netbeans have. OK shoot me now, but I think it would be awesome :o)