4 ms·

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:

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
- artagnon 13y ago
  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/master/auto-complete-clang-async.el#L43 https://github.com/Golevka/emacs-clang-complete-async/blob/m...
  - sa1 13y ago
    The clang-complete is also a running process and gets spawned just once.
artagnon 13y ago
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/msg00538.html http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg005... [2]: http://www.sxemacs.org/ http://www.sxemacs.org/ [3]: http://vimdoc.sourceforge.net/htmldoc/eval.html#libcall%28%29 http://vimdoc.sourceforge.net/htmldoc/eval.html#libcall%28%2...
- davexunit 13y ago
  If the Guile-Emacs project is successful, GNU Guile will be the VM in which Elisp and Scheme code is run. This means that Emacs will finally gain such features as an FFI.
bad_user 13y ago
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 [1], hopefully it will bear fruits as planned by its author. [1] http://lighttable.com http://lighttable.com
tkf 13y ago
> The takeaway is that Elisp needs to learn to interface with other languages better. 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 https://github.com/kiwanami/emacs-epc He was also inspired by the article.

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

artagnon 13y ago
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/master/auto-complete-clang-async.el#L43 https://github.com/Golevka/emacs-clang-complete-async/blob/m...
- sa1 13y ago
  The clang-complete is also a running process and gets spawned just once.

artagnon 13y ago

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/msg00538.html http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg005... [2]: http://www.sxemacs.org/ http://www.sxemacs.org/ [3]: http://vimdoc.sourceforge.net/htmldoc/eval.html#libcall%28%29 http://vimdoc.sourceforge.net/htmldoc/eval.html#libcall%28%2...

davexunit 13y ago
If the Guile-Emacs project is successful, GNU Guile will be the VM in which Elisp and Scheme code is run. This means that Emacs will finally gain such features as an FFI.

bad_user 13y ago

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 [1], hopefully it will bear fruits as planned by its author. [1] http://lighttable.com http://lighttable.com

tkf 13y ago

> The takeaway is that Elisp needs to learn to interface with other languages better. 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 https://github.com/kiwanami/emacs-epc He was also inspired by the article.