91–100 of 115 posts
Earlier quoted context omitted.
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.
I meant human efficiency, not the computer kind.
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 headi…
I don't think Sublime is heading the ways of IDEs.. why do you think so?
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 impo…
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 [1], hopefully it will bear fruits as planned by its author.
Earlier quoted context omitted.
I don't think Sublime is heading the ways of IDEs.. why do you think so?
What do you mean by IDE? For me, IDE, is just an editor with some good integrations with tools I use.
Earlier quoted context omitted.
What do you mean by IDE? For me, IDE, is just an editor with some good integrations with tools I use.
Yes, but I haven't seen any great Sublime extensions yet - there isn't even a good Git integration.
Earlier quoted context omitted.
I meant human efficiency, not the computer kind.
In what way is Emacs inefficient for humans?
http://en.wikipedia.org/wiki/Emacs#Emacs_pinky
As a novice Vim user who has at times wanted to try out Emacs, this has always been an irritation. I think it's telling that one of the suggested work-arounds according that article is:
> Emacs' built-in "Viper-mode" that allows use of the vi key layout for basic text editing and the Emacs scheme for more advanced features.
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 impo…
In general, the problem is that Emacs does not have an FFI (mostly due to "philosophical" nonsense? see discussion [1] and SXEmacs [2]). Even Vim has a (somewhat primitive) FFI [3]. [1]: http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg005... [2]: http://www.sxemacs.org/ [3]: http://vimdoc.sourceforge.net/htmldoc/eval.html#libcall%28%2...
Earlier quoted context omitted.
I meant human efficiency, not the computer kind.
In what way is Emacs inefficient for humans?
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 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_.
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 impo…
This is exactly why @kiwanami developed EPC (a general RPC protocol/libraries for Emacs) and why I wrote Python binding: https://github.com/kiwanami/emacs-epc
He was also inspired by the article.