Emacs v. Vi Is Rooted in the Love of Lisp

http://stevengharms.com/blog/2005/07/24/emacs-v-vi-is-rooted-in-the-love-of-lisp/

by gnosis • 13 years ago

46 55 13 years ago

kirinan• 13 years ago

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.

busterarm• 13 years ago

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.

gems• 13 years ago

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

elehack• 13 years ago

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.

pilgrim689• 13 years ago

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

ryankey721• 13 years ago

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?

dhruvmittal• 13 years ago

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

stray• 13 years ago

"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

qu4z-2• 13 years ago

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)

graue2• 13 years ago

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.

MHordecki• 13 years ago

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

Zakharov• 13 years ago

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

johncoltrane• 13 years ago

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

dllthomas• 13 years ago

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

Arelius3• 13 years ago

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.

gnosis2• 13 years ago

"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

samdk• 13 years ago

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.

taeric• 13 years ago

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.

tikhonj2• 13 years ago

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.

Arelius3• 13 years ago

You've just made my day with C-#

linuxhansl• 13 years ago

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

fusiongyro2• 13 years ago

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.

charlieflowers• 13 years ago

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

gnosis2• 13 years ago

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.

mrmagooey• 13 years ago

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.

cheez3• 13 years ago

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.

maigret• 13 years ago

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

justinrstout• 13 years ago

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.

mturmon• 13 years ago

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.

narrator• 13 years ago

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.

niggler• 13 years ago

    set -o vi

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

krichman2• 13 years ago

you have changed my life

mitchty• 13 years ago

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.

rsl7• 13 years ago

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.

falcolas• 13 years ago

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.

fusiongyro2• 13 years ago

M-x variable-pitch-mode

greggman3• 13 years ago

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.

greggman3• 13 years ago

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.

greggman3• 13 years ago

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

tsm• 13 years ago

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

krichman2• 13 years ago

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

tikhonj2• 13 years ago

Consider trying evil mode for Emacs.

crymer112• 13 years ago

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

derleth• 13 years ago

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

pjmlp2• 13 years ago

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

eruditely• 13 years ago

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

Arelius3• 13 years ago

> "Unix/Linux/BSD"

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

crymer112• 13 years ago

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

pjmlp2• 13 years ago

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

Emacs v. Vi Is Rooted in the Love of Lisp

Related Stories