Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs is Dead (2010)

tkf.github.io

Post reply on HN
Print view View original

81–90 of 115 posts

Re: Emacs is Dead (2010)

#81

Post by artagnon »

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

[2]: https://github.com/Valloric/YouCompleteMe/blob/master/autolo...

[3]: https://github.com/Valloric/YouCompleteMe/blob/master/cpp/yc...

[4]: https://github.com/brianjcj/auto-complete-clang/blob/master/...

[5]: https://github.com/trogdoro/trogdoro-el4r

Re: Emacs is Dead (2010)

#82

Post by easytiger »

monkmartinez wrote: post #55
philsnow wrote: post #38

Earlier quoted context omitted.

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.

if you don't need the features or bug fixes don't upgrade. You simply have status anxiety

Re: Emacs is Dead (2010)

#83

Post by artagnon »

jamii wrote: post #11

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.

I would have some hope if it were an open source project, and I were able to read the code.

Re: Emacs is Dead (2010)

#84

Post by sa1 »

artagnon wrote: post #81

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…

I use this async version[1] for completion, it doesn't spawn clang everytime.

[1]: https://github.com/Golevka/emacs-clang-complete-async

Re: Emacs is Dead (2010)

#85

Post by Makkhdyn »

artagnon wrote: post #83
jamii wrote: post #11

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.

I would have some hope if it were an open source project, and I were able to read the code.

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

Re: Emacs is Dead (2010)

#86

Post by artagnon »

sa1 wrote: post #84
artagnon wrote: post #81

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…

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

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/m...

Re: Emacs is Dead (2010)

#87

Post by solomatov »

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

Re: Emacs is Dead (2010)

#88

Post by sa1 »

artagnon wrote: post #86
sa1 wrote: post #84

Earlier quoted context omitted.

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

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/m...

The clang-complete is also a running process and gets spawned just once.

Re: Emacs is Dead (2010)

#89

Post by artagnon »

artagnon wrote: post #81

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

Re: Emacs is Dead (2010)

#90

Post by swah »

solomatov wrote: post #87

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?
Post reply on HN