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

51–60 of 115 posts

Re: Emacs is Dead (2010)

#51

Post by goldfeld »

jzelinskie wrote: post #47
tmhedberg wrote: post #10

Earlier quoted context omitted.

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 VimScr…

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 fe…

I'm reaching a point where I can consider myself at home with VimScript (moreso the bigger investment has been on the built-in vim functions and not on the language proper), and I'm becoming increasingly active within the Vim community. I can tell I don't have any plugins in Python/Ruby and actively avoid them, seeking lightweight alternatives instead, and I would detach myself from the community if VimScript were to be phased out in favor of Python (don't have too much love for it.) Fortunately none of that is going to happen.

Re: Emacs is Dead (2010)

#52

Post by tkf »

bitwize wrote: post #20

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…

I think "maximum extensibility" is not the philosophy of Emacs. Remember how long it took to have FFI support in Emacs (it was discussed in the article). Also, even with FFI, it is not possible to load non-free libraries. I think this shows some discrepancy from the philosophy to achieve "maximum extensibility". I would say GPL does not allow "maximum extensibility".

So the next question is: does the philosophy the author speaks of matches with the one of GPL, or rather, the one FSF and Stallman have in mind? Actually, I think these philosophies are different. If I remember correctly, in Emacs mailing list sometime ago, Stallman rejected idea of adding function to gcc to dump parse tree (or something similar) to use gcc from other software (I can't find the link right now). This was because non-free software could use gcc via CLI and "steal" the data from free software. Now, although it is the other way around, Emacs can use non-free external program. It matches with the philosophy by Matsuyama but I doubt that Stallman says it is the philosophy of Emacs.

I would say this philosophy is for author of Emacs Lisp program (though this was not what Matsuyama was talking about). You have many options. You could choose "maximum extensibility" but actually it is not doable due to GPL. You can follow FSF's philosophy (I am not sure what is it, but I believe there is). Somewhere in between, there is philosophy proposed by Matsuyama and it reflects current situation of Emacs very well, and I like it.

Re: Emacs is Dead (2010)

#53

Post by tkf »

TeMPOraL wrote: post #48
tkf wrote: post #35

Earlier quoted context omitted.

Some awesome Emacs Lisp programs that relies on external programs: mu4e: http://www.djcbsoftware.nl/code/mu/mu4e.html not much: http://notmuchmail.org/ EDBI: https://github.com/kiwanami/emacs-edbi ropemacs: http://rope.sourceforge.net/ropemacs.html RSense: http://cx4a.org/software/rsense/index.html GCCSense: http://cx4a.org/software/gccsense/index.html emacs-ipython-notebook: http://tkf.github.io/emacs-ipython-notebo…

And then again, they are pain in the arse (if not impossible) to use on Windows. One of the benefits of ELisp extensions is that they are multiplatform.

I agree some of them are harder to setup in Windows. But it helps (or forces) developers to make these tools and languages cross-platform, which is good, I think. And I guess making them cross-platform is actually easier than implementing them purely in Emacs Lisp.

Re: Emacs is Dead (2010)

#54

Post by evincarofautumn »

joshAg wrote: post #31
bitwize wrote: post #20

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…

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

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.

Re: Emacs is Dead (2010)

#55

Post by monkmartinez »

philsnow wrote: post #38
monkmartinez wrote: post #33

Earlier quoted context omitted.

I'm not sure about you, but the level of effort required to keep my emacs.d up to date and the level of effort required for each project has turned me away from emacs as my main development environment.

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.

Re: Emacs is Dead (2010)

#56

Post by kindahero »

camperman wrote: post #45
erikcw wrote: post #36

Earlier quoted context omitted.

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! :-)

My favorite of TKF's packages is 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.

Actually, auto-complete was written by Matsuyama (original author this article), though tkf has contributed to the project.

Re: Emacs is Dead (2010)

#57

Post by monkmartinez »

erikcw wrote: post #36
monkmartinez wrote: post #25

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.

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! :-)

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.

Re: Emacs is Dead (2010)

#58

Post by npsimons »

jongraehl wrote: post #2

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

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

Re: Emacs is Dead (2010)

#59

Post by quotemstr »

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.

Re: Emacs is Dead (2010)

#60

Post by jzelinskie »

goldfeld wrote: post #51
jzelinskie wrote: post #47

Earlier quoted context omitted.

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 fe…

I'm reaching a point where I can consider myself at home with VimScript (moreso the bigger investment has been on the built-in vim functions and not on the language proper), and I'm becoming increasingly active within the Vim community. I can tell I don't have any plugins in Python/Ruby and actively avoid them, seeking lightweight alternatives instead, and I would detach myself from the community if VimScript were to…

I do often opt for the slower, pure vimscript extensions in order to avoid having to remember to compile specific ones. Hypothetically, if vim had an embedded form of Lua, it could satisfy the people who want a familiar scripting language and it wouldn't be dependent on whatever version of the language the system has installed. I think that would be a excellent choice if you were writing a brand new editor.

To be perfectly honest, I think so many vim users (including myself) don't know vimscript [in depth] because they can easily find everything they need already.

Post reply on HN