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.
Emacs is Dead (2010)
11–20 of 115 posts
Re: Emacs is Dead (2010)
#12I 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]…
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.
Re: Emacs is Dead (2010)
#13This 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.
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.
Re: Emacs is Dead (2010)
#14I 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]…
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".
Re: Emacs is Dead (2010)
#15The 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.…
[deleted]
Re: Emacs is Dead (2010)
#16I 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]…
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.
Re: Emacs is Dead (2010)
#17I 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]…
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 jus…
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!
Re: Emacs is Dead (2010)
#18I 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]…
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.
Guile integration may matter, assuming it happens (not everybody seems happy: 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?
Re: Emacs is Dead (2010)
#19I 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]…
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_.
Re: Emacs is Dead (2010)
#20This 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" :)