Emacs v. Vi Is Rooted in the Love of Lisp | Hacker News Reader

Emacs v. Vi Is Rooted in the Love of Lisp

stevengharms.com

46 pointsgnosis56 comments

I basically agree with the final conclusion, but I don't think the example given--deleting five lines of text--actually supports it at all. The author is claiming that vim's way of doing it is cryptic (normal 5dd), and then says this about emacs' way:

    Define a function for a ‘universal’ n-many operator
    ( Control-U ), pass that an iteration count integer,
    have that perform the pre-defined global
    kill-line-of-text operation ( Control-K ).

Vim's solution is conceptually the same: you're in normal mode because that's where you do text manipulation, prefixing commands with numbers is the standard way of repeating an action a fixed number of times, and dd is the pre-defined global delete-line-into-a-buffer operation.

They're both cryptic until you understand what's happening--the only real difference is that vim is less explicit, because this kind of action is exactly what vim is best at.

I suspect that there's a better example for demonstrating emacs' power, but I don't know emacs well enough to provide it. Vim is probably my favorite piece of software, but there are certainly things emacs does better.

Hmm... I think the difference is that the way a user would define how ctrl-k and ctrl-u work is identical to how the editor already implemented them. And that this is actually in a language you may use elsewhere. Whereas in vim, the implementation language is far removed from the customization language. (Well, maybe.)

And yeah, I consider vim to be almost sacrosanct. Especially with the fugitive.vim plugin.

Yeah, that example is not particularly good, especially since you can do C-# (where # is the number) in Emacs, which is qualitatively the same as vim. (It's just as magical.) I always use that instead of C-u because it's easier to type.

Ultimately, the magic of Emacs is not in the key bindings; this is why Evil mode is not fundamentally against the Emacs philosophy. The magic is with how the editor feels just like an extension of the underlying elisp.

You've just made my day with C-#

My favorite programming language is Common Lisp. My favorite text editor is vim. I have no cognitive dissonance about this.

More to the point, the extensibility of an editor and the core editing functionality are orthogonal. As they say, "Emacs is a great operating system--all it needs is a decent text editor."

And I would be absolutely thrilled if the main scripting language in vim was a Lisp.

Consider trying evil mode for Emacs.

I actually don't give two hoots about elisp, in fact I'd prefer the language was python. I use emacs for three reasons:

- I like the default keybindings for pretty much everything

- I like that the concept of a buffer is not connected to the concept of a window or frame or anything. That I can have the same buffer open twice in separate windows is useful.

- It's cross platform & I can be productive on remote servers if necessary.

My least favorite days are when I need to customize something and rather than it taking 15 minutes it takes 3 hours as I refresh my memory on elisp. I would prefer to spend this time being actually productive.

This means you're not writing enough elisp and if you amortize it over a year, then you are spending as much time as you should.

FWIW, I have about 1KLOC in elisp custom code.

Not that I disagree much with your point, but I remember Richard Stallman himself told to have almost no customization in his Emacs (can't find a reference now but feel free to prove me wrong). This tend to be very useful while using the editor on lots of different machines (and yes, I know of remote editing).

You could probably say that Emacs originally was Stallman's customizations. He made the editor how he wanted it.

If I wrote my own editor, I probably wouldn't need any customizations either.

Now, when I am annoyed at what I believe to be an absurd default setting, I'm going to clench my fists and grumble,"Stallman!"

I do that all the time!

I've thought long and hard about this for a few years, and I've reached the conclusion that the best of all world is to use Emacs with Evil (vim emulation). So I get Vim modes and keyboard efficiency with the ultimate configurability of Emacs. (Ironically, though, I've been doing a lot of C# lately, and of course there I'm using Visual Studio, lol).

I have to agree.

After over 20 years of very happily using vim and other vi-clones, I'm in the process of making emacs+evil my main editor.

Making the switch is slow and painful for this veteran vim user who has perfected his vim environment, but I can already see that the emacs environment that I build will be superior... eventually.

Plus, I get the joy of scripting my editor in elisp and eventually guile (I hope). No more vimscript for me!

That said, vim is a wonderful editor. Even if vim ultimately isn't as flexible as emacs, it's still incredibly powerful; and there's a lot of cross-fertilization going on between the two editors, with vim users getting inspired by emacs features and packages and writing vim equivalents and vice-versa.

I use vi and emacs all the time, and it appeared almost random which one I pick. For code editing I also use Eclipse.

After I read an article like this a few months ago I started to keep track of which editor I use for what. Here's what I tend to do (not always, but most of the time):

- code editing of big code base: Eclipse

- casual code editing (of a few files): Emacs or vi

- Single file code editing, config file editing: vi

Have you tried eclim? I'm trying to hook it up to Emacs, but since I use Netbeans rather than Eclipse it's been less perfect going so far.

One good thing about Emacs is all the key-bindings work by default in the bash shell. If one remaps control to Caps Lock it makes it a lot easier on the hands.

Org-Mode is nice. So is the minibuffer. I can start a regex by yanking text from the main buffer and then un-yanking text into the mini-buffer where the regex is being edited.

Another nice feature is that Emacs is very fast when handling very large files and files with very long-lines. Most text editors choke on these kinds of files.

    set -o vi

sets vim bindings for bash (and there's a similar thing for the libreadline)

you have changed my life

aka:

    echo 'set -o vi' >> ~/.inputrc

And you no longer need to have it in your bashrc at all any longer because bash uses readline.

I'm not sure it's very constructive to explain the editor wars in a short, non-technical blog post. This article provides little useful technical information and a lot of extraneous verbal fluff. The comparisons to various philosophical works were particularly pretentious and painful to read. It doesn't seem like this article contributes anything substantial to the debate.

You're totally correct ("little useful technical information").

However, at this point, the editor wars have become a stage on which to explore viewpoints about how things should be, and how we got to where we are.

In particular, it's not about resolving the question of which to choose.

I'm so happy to see that this article is old. There is no reason to continue the ridiculous editor wars. emacs and vi have really held back innovation imho with their slavish devotion to the tty paradigm. this problem is that they are good enough so that innovation has slowed. Feels like we're stuck in the 70s but with web browsers.

You had me until you started talking about holding back innovation.

There may be room for innovation in the text editing market, but I don't see vim and emacs holding anything back just by being good text editors.

M-x variable-pitch-mode

I completely agree with you. I believe there are tons of things that could be done better, many I'm sure I'm not creative enough to imagine, if the editor wasn't tied to tty.

Here's one idea which I'm sure sucks but....I wish a code editor could show images inline where appropriate.

I'd personally like to see HTML style comments inline, where by default the comments are shown styled and you can press some hot key to edit them as html, and maybe by default they edit in wysiwyg mode.

I know some programmers will complain they won't then be able to read the comments in their editor of choice but that's exactly the point. tty only = stuck in the 70s. How is that any different than if HTML never supported colors, fonts, images, svg, etc? Sure, it's code but some code is better explained through diagrams. I shouldn't have to go find a manual to see the diagram, it should be in the code. And no, text based digrams with +----+ etc are not a full substitue for real images. Heck, I'm sure some of you would like to see MathML displayed in it's rendered form inline in a description of some math function instead of only it's source form.

I'm disappointed you downvoters are so stuck in your ways that you can't imagine it's possible things could ever be improved by getting out of text mode.

And now we see IntellJ using graphics to show you inline references to icons and colors as just one example of what graduating to a graphics can provide.

Yep, Text only forever!! :-(

I do prefer IDEs to Emacs/vi(m), specially for large codebases.

However for Lisp users, Emacs can be configured to achieve parity with what Lisp Machines used to offer, which is quite nice.

http://www.loper-os.org/?p=932

This is definitely a nitpick, and I catch myself saying the same thing as well, but Mac OS X (since Leopard) is a Unix. Certified Unix 03. There is no need to say "Unix / Linux / Mac OSX", just "Unix/Linux" or even better, "Unix/Linux/BSD".

> just "Unix/Linux" or even better, "Unix/Linux/BSD".

Or just "Unix", because there is no functional difference between the OSes that legally get to call themselves "Unix" and those that don't which derives solely from their rights to a name.

Or, to put it another way, how is z/OS more similar to MacOS X than NetBSD is?

Except those little POSIX functions that tend to have platform specific or undefined behavior.

The point of language is communication, not functional expressive equivalency. A good chunk of people would miss the Unix = OSX.

> "Unix/Linux/BSD"

How is that better? BSD is at least as much Unix as OSX.

FreeBSD (and Darwin) are not UNIXes, despite being compatible, since they aren't certified. Unless you fork over some change for the certification, the best you can be is "Unix-like".

This is actually folly: both vimscript and lisp are both turing complete language (read can both make a computer do everything a computer is capable of doing), so even know LISP might have nicer syntax/cooler paradigm, what have you: it doesn't matter, you can achieve the same thing in VIM Script. I am a VIM user, although not a fanatical one, I see the merits of having a language like eLISP for emacs, but honestly I think they are both outdated. If I wasn't so partial to using a command line editor (I use the terminal a lot), i'd switch to Sublime text 2 because it uses python, and I'd rather use a modern scripting language than either vimscript or eLISP.

I've never been able to get comfortable using emacs no matter how hard I try.

Even vim is just bearable for me and if I'm not using Sublime Text 2, I'm probably using nano.

I hear what you're saying about having a CLI at the ready though. If SublimeXiki worked any better (or is it just me?), I'd say you could easily switch. I'm hoping maybe something coming down the pipe in ST3 will make our situation a little better.

>This is actually folly: both vimscript and lisp are both turing complete language (read can both make a computer do everything a computer is capable of doing), so even know LISP might have nicer syntax/cooler paradigm, what have you: it doesn't matter, you can achieve the same thing in VIM Script.

Just because two different things, like two different languages, have the same potential doesn't mean they're equal.

Yes, strictly speaking, Turing completeness implies a certain formal equivalence between the two programming languages.

But does this does not an equivalence between systems make, for at least two reasons:

1. Different languages encourage, and make easy, different modes of thought. Lisp promots a certain view of building hte world out of recursive, replaceable pieces.

2. Different systems provide different levels of access to their internals. The vast majority of Emacs is written in Lisp, and can therefore be hooked and rewritten. Its C code is an Emacs interpreter and text editing/rendering engine. Vim provides a great deal of scripting capability and many hooks, but that's still hooks on a system rather than a system that can be freely rewritten on the fly. It feels very different, and can allow different things if Vim is missing the hook you need.

Saying they're both turing complete isn't saying much. Firstly, even when comparing turing complete languages, it can be sometimes easy to pick out a superior one with respect to development (e.g. Brainfuck VS Haskell, also see http://en.wikipedia.org/wiki/Turing_tarpit). Secondly, it's not just about turing completeness, it is also about APIs. These languages -- vim script and emacs lisp -- don't live in total isolation, they live in an environment. Thus, it is not only the language we are comparing, but also the environment/API (what can you call? how is it called? how easy is it to do X? how many tools are available at-hand VS tools I have to build myself? etc.)

Out of curiosity, what do you think is outdated about the languages? What does Python fix about the languages, especially in the cast of text editors?

Correct me if I'm wrong, but can't extensions for vim 7.3+ be built in python (as long as vim is built with python support)?

"But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub." -from beating the averages

In fairness, elisp is pretty weird. Doesn't it still use dynamic scope? :P

Sincerely, the guy who writes stuff like

  execute a:method . resolve(expand('%:p:h') . "/" . tolower(a:entry) . ".ext")

(Yes, vimscript is insane, too)

As of Emacs 24, either dynamic or lexical binding is available. Dynamic binding is the default though.

Python scripting inside Vim has been supported for a while. I've never seen a Vim plugin written in it, though, which seems odd given the gripes about VimScript.

Python API is severely limited. For many use cases, you have to issue VimScript commands from your Python script anyway.

The default vim shipping with Ubuntu (12.04, not sure about newer versions) doesn't have Python support.

Are you sure? My VPS runs Ubuntu 12.04.2, only has the vim-common, vim-runtime and vim-tiny packages installed, and `:python echo "Hello world"` works fine.

Parts of Sparkup and UltiSnips are written in Python. I believe YouCompleteMe uses Python too.

They are both Turing-complete, so they can both compute the same things. This is not the same thing as saying they can both do the same things - as others have mentioned, there's the question of what they have access to (hooks/API).

This is a misleading statement. Javascript for instance is turning complete even when hosted in the browser. But I cannot write a file to an arbitrary part of disk.

"Beware of the Turing tar-pit[1] in which everything is possible but nothing of interest is easy."

- Alan Perlis

[1] - https://en.wikipedia.org/wiki/Turing_tarpit

Reply on news.ycombinator.com