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.
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.
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.
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."
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.
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).
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).
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
How are you defining power user? I feel like I have a solid command of the key bindings for both editors, but I only really know the Emacs ecosystem.
My editor use is similar to linuxhansl's: Eclipse (with Emacs+) for day-job Java, Emacs (in Evil mode) for other local editing, and vi(m) when SSH'd or the like.
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.
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.
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.
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.
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.
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.
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".
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".
> 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?
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.
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.
"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
>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.
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.)
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.
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.
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.
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.
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.