Hacker News Reader

Comment by bitwize | Hacker News Reader

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 one, is "maximum extensibility". Whether that be with elisp or external processes matters not.

EDIT: forgot the word "conventional" :)

View on HN

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

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.

In what way is Emacs inefficient for humans?

My guess would be the Emacs pinky:

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.

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 its buffer management at all.

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

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

The screeching brakes sound of context switches in Vim is not more "efficient" than just pressing a key combination to perform whichever transformation on text you wish to effect in Emacs.

I use Emacs to edit text, and I have limbs I'd rather lose than have to perform that task with Vim's airbag in my face.

> Vim is not more "efficient" than just pressing a key combination

Vim and Emacs both use key combinations... Vim's just require fewer fingers at once. You type Vim key combinations as you would type words in a language with a latin alphabet.

I think a lot of features -- especially if you want them accessible inside INSERT mode -- are accessible through CTRL+letter, no? At least omni-completion, the most useful one, used to be when I last tried it. (Has that changed? I'm not doing much editing in vim these days, so I may be wrong.)

Any command that I can think of can be mapped to work while in insertion mode.

The key however is understanding that if you are insertion mode, then key sequences start with the escape key, or, insertion commands are completed with the escape key. There is no "context switching". No more-so then having to press ctrl along with the rest of your key sequence in Emacs is "context switching".

Sorry, I meant to say "conventional wisdom".

eh ? like your parent comment pointed out - it's a quip by us vi users, not "wisdom" (conventional or otherwise) :-)

its arguable there are far less emacs commands to learn to get started coding compared to vims modes and key combinations.

Actually emacs has a decent text editor now:

http://www.emacswiki.org/emacs/Evil

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.

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

Reply on news.ycombinator.com