Emacs is Dead (2010) • Hacker News Board

Re: Emacs is Dead (2010)

#111

Post by danielbarla » Tue, Jun 04, 2013, 6:24 AM UTC

swah wrote: post #110

intractable wrote: post #105

Earlier quoted context omitted.

> underline an arbitrary line of text with '=' characters. In vim that's 11 keypresses across 3 operations Sounds like a vimgolf challenge to me. Here's my entry: YpVr=

I'm wondering now that the creativity to come up with those things might actually be beneficial to coding.

I'd agree with that, and also - an intense dislike of unnecessary repetition / work is definitely a good thing. I'm not sure using Vim causes that, but it definitely reinforces it.

For those that are interested, I would recommend "Practical Vim", and it includes many examples (including the above one) which really accelerate the learning process:

http://pragprog.com/book/dnvim/practical-vim

There are definitely cheaper alternatives (including free ones), but this book really laid the concepts out very clearly for me.

Re: Emacs is Dead (2010)

#112

Post by kaffiene » Tue, Jun 04, 2013, 11:17 AM UTC

I know this will immediately mark me as a heretic, but I am a long time and current Emacs user, so this comes from a place of love, really :o) -- I believe the best thing for Emacs would be to be rewritten in Clojure with Clojure as the scripting language. This would: * Maintain the Lisp culture * Speed up the whole enterprise * Allow multithreading * Remove the need for most external programs * Work across platforms (many Emacs extensions or programs rely on Unix commands which don't come with Emacs) * Provide the ability to apply a decent UI - not that I have any on my Emacs - I turn the toolbar off, but dialogs for projects / browsers could be better (read: "not suck") * Would allow the ability to immediately get a bunch of proper language parsers like Yegge's JS mode - all the ANTLR parsers are immediately available to use in Clojure and would give emacs the language-aware goodness that Eclipse and Netbeans have.

OK shoot me now, but I think it would be awesome :o)

Re: Emacs is Dead (2010)

#113

Post by regularfry » Wed, Jun 05, 2013, 11:03 AM UTC

intractable wrote: post #105

regularfry wrote: post #98

Earlier quoted context omitted.

Try this task for an example: underline an arbitrary line of text with '=' characters. In vim that's 11 keypresses across 3 operations, possibly less if there's a shortcut I haven't thought of. How many keypresses does emacs take out of the box? 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 it…

> underline an arbitrary line of text with '=' characters. In vim that's 11 keypresses across 3 operations Sounds like a vimgolf challenge to me. Here's my entry: YpVr=

Well, that Vr= soundly beats my :s/./=/g.

Re: Emacs is Dead (2010)

#114

Post by hollerith » Wed, Jun 05, 2013, 9:57 PM UTC

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 conventional wisdom that "Emacs is a good operating system, it just needs a decent text editor".

If that's the conventional wisdom, it is not particularly wise.

Emacs is much more like a Unix shell than any operating system I have ever heard of. Specifically, both Emacs and the shell fork and exec other programs a lot; a significant fraction of those programs communicate with Emacs or the shell via a PTY or a Unix pipe. In contrast, Eclipse does very little of those two things, according to the OP.

Re: Emacs is Dead (2010)

#115

Post by hollerith » Thu, Jun 06, 2013, 2:49 PM UTC

npsimons wrote: post #58

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

>I love emacs to death, but the singlethreadedness is such a pain. Especially if . . . or just a blocking external process (when you're trying to run two or three or more).

I am having trouble imagining how you end up in a situation where Emacs is waiting on a blocking external process while trying to run other external processes.

There two kinds of external processes inferior to Emacs: those that communicate with Emacs synchronously and those that communicate asynchronously.

The inferior shell process in a shell-mode buffer is probably the most familiar example of the latter. (Any mode derived from comint mode is an example.) Your Emacs is never waiting for an asynchronously-communicating external process, is it?

The prototypical example of a process that communicates with Emacs synchronously is when Dired forks and execs the ls command to get a directory listing. I never find myself waiting for this ls command. The only external process I notice myself ever waiting for is the movemail program distributed with Emacs -- and that never took more than around 10 seconds (and usually a lot less) even on early-1990-vintage computers like a 386. So I am having trouble imagining what your "when you're trying to run two or three or more [external processes]" refers to.

Parenthetically, I could eliminate the delays caused by movemail by rewriting vm-get-new-mail to use async io when it is finished like M-x man uses. Adding threads to Emacs would not be necessary.

But then I have very little experience of or knowledge Windows. Is this waiting you refer to a Windows-only thing?

The OP maintains that it is probably a good thing that Emacs is not multi-threaded, and after 20 years of using Emacs and hacking on Emacs I tend to agree -- but my experience is almost all on Unix-like systems.