The problem is, the emacs-world and the vi-world have substantial islands of non-overlapping functionality. It just happens that nobody in the emacs universe cares about javascript. The only sane javascript mode, js2-mode, does a decent job of highlighting the local syntax, but indentation is hideously inconvenient and ecb has no support for javascript at all. Which means I can’t work on large projects. I still do all my c work and perl work in ecb, but because I make a living coding in javascript, I had to abandon emacs and go into a year-long macvim session.

Fortunately, TagList does a pretty good job marking up javascript. It, too, does not properly understand the language, but at least it does not break and creates reasonably good overviews for my files and (some) functions therein. Indentation is perfect.

Emacs has become a frontend to subversion. And this reversal of preferences has occurred simply due to an accident. One of the most popular programming languages simply failed to jump the adoption threshold in emacs-world.

A more valid critique would be “why not have ‘jj’ carry out this role by default since is much more comfortable than .

There are other even bigger problems. One that comes to mind right now is with word wrap. When you wrap words, the go all the way off the right hand margin and show up on the left hand margin. This is great for plain text documents, but if I have a nested structure (think if-else) which is tabbed, I want the wrapped text to be correctly indented. This is especially a nuisance for LaTex. There is, AFAIK, no possible way to do this with vim.

It’s best to think of Vim as the world’s coolest Regular Expression. No other Regular Expression will ever come close to it. However, it is not a Context Sensitive language. Therefore, there are some things it can not do.

:e something and then Ctrl-o to go to last edit location until back in previous file

Actually, it’s the right command, but the wrong text object. You probably DO want either gq or =, however you want to operate on the current XML tag. You’d do this with gqat or =at.

This is absurd. What made the author think he was required to use Esc at all? Just remap practically any keys (within Vim) you like to Esc and problem solved. I use jj. Switching between normal and insert mode is so fast the editor essentially feels modeless.

I have no opinion on which editor is better overall (and I’m not a coder so my opinion is worthless here anyway) but people who bash Vim because of the alleged need to use the Esc key simply don’t realize how easy it is to customize Vim to your liking.

Also, the Kinesis Advantage keyboard solves the pinky issues, but after about 12 years of using it, I’ve started to get thumb issues, as the left thumb is what I hit the ctrl and alt keys with. Has this happened to anybody else?

Thus, I’m toying with going to vim like bindings to ease the work on my ctrl-key thumb….

I highly recommend the BufExplorer plugin to manage your buffers too.

And of course, mapping :bnext and :bprev to saner keybindings (I have Ctrl-Left/Right) will help you.

Emacs is definitely more mainstream within the Haskell world, though :)

But occasionally I look at Emacs again and lately have tried using it to edit Haskell. Using Emacs really shows some of the weaknesses of Vim. The power of haskell-mode to automatically indent the code is amazing. In Vim I spend a lot of time hitting the tab key or << to move things around. Overall the Emacs user interface is more polished, I think–it has great tab completion, for example.

On the other hand when I'm in Emacs I feel like I'm using Microsoft Word because it just takes so long to navigate the file. I'm using to navigating in Vim command mode, where everything is a few keystrokes away. With Emacs it seems to me I have to hit a lot more buttons. In Vim for instance I often use f or F to go to a certain character on this line. ";" repeats it. Maybe Emacs has an equivalent?

My current impression is that one can be equally productive in either editor, just productive in different ways. I've liked looking at Emacs to see how it does things differently, and to see some things done so well, but I don't think it will actually make me more productive–especially not so much more productive that it will offset the time spent reading Emacs docs. I'd imagine the same is true for someone going from Emacs to Vim. It takes so long to get really proficient in either editor that, by the time you do that, it's just too much trouble to switch.

I'm glad we have both these editors so each person can choose what is best for him or her.

Ask any heavy Emacs users about their left little finger experience.

It’s good to see that you’ve run into pretty much the same irritations that I did, and that emacs really does handle those better. I’ve really wanted vim to work for me, but there’s too much stuff “out of the box” that just doesn’t work. I think a lot of vim users have adapted themselves to vim rather than the other way around.

I might miss a few commands like :norm, but we’ll see.

Consider this example:
if a == b:
print “some text”
print “some more text”

How is Vim supposed to know whether the second print statement should belong to the if block or not?

If you try autoindenting e.g. a file in C, XML or JavaScript however, Vim would correctly adjust the indentation to the syntax.

Also you can consider the viper mode.
Emacs does vi ;)

The indenting control is simpler, and can be done by setting some different options.
Again, I’ve had no problems at all with indent control. I’m surprised you turned it off.
What’s the specific problem?

And for those who say roll your own :( Who wants to deciper cryptic regular expressions where almost everything has to be escaped twice? And if it was that easy wouldn’t major filetypes like HTML, XML and Javascript be rock-solid by now?

Still, I love Vim. I find editing on Vim is much faster than having to use the mouse or doing finger gymnastics that require 3 or 4 keys. I can easily switch between Apple and PC keyboards.

Like someone else said, 8 months is too early to give up, but it sounds like you haven’t tried. Your issues don’t add up. You’re still a vim newbie. This article is misleading because it’s uninformed and inaccurate.

The big thing about vim is the command mode. Obviating the need for control keys for everything just breaks the keyboard out into a whole new world. Operations that used to take seconds now take sub-seconds (as fast as you can type) and a whole lot more operations are available. The only editor that could beat vim would be another editor that uses a command mode, but there aren’t any.

Syntax highlighting plugins do often skip the laborious picky little exceptions that would slow down the interface on low spec machines. You can write your own.

Indentation was originally designed for C but there are multiple indentation control mechanisms. Roll your own. It’s not hard.

For ‘the paste buffer’ read ‘the default paste buffer’. If you want to pick and choose what goes into your paste buffer and what doesn’t you need to start naming your paste buffers. Vim’s doing the best job here.

Vim loves having lots of files open. There’s buffers and windows and splits and all sorts of ways of controlling your file lists.

You’re upset about not creating a new window because you haven’t figured out how to work with multiple files yet. I never need or want an additional window in vim.

No-one uses gqap for formatting XML. It’s just not intended. You can set a command to call an external formatter if you need to. This particular issue really reveals how little you’ve got across what vim does. You are complaining that gqap doesn’t format XML? No one told you it would!

However, it’s not like it’s a dichotomy. I’ve taken viper mode and have modified it in such a way so that rather than trying to override Emacs, it harmonizes with it. I’ve also implemented visual-select mode, so Emacs commands work with the perfectly, but it also brings a lot of the goodness of the feel of vim.

Perhaps if (when?) I release it, we can and the holy war once and for all. :-)

I think I will call it vi-harmony. Or something cheesy, perhaps a useless recursive acronym?

Bill

def test():
print “hello”
if a ==b:
pass
else:
pass

The buffer list will show an “h” if a buffer is loaded and hidden (again you need :set hidden for this) and if that “h” isn’t there then a buffer is not in memory unless it’s visible.

I’ll take your points one by one:

1 – ESCAPE key

As many others have noted, it can easily be remapped to another key or combination of keys. Though, personally, after using vim for a while, I don’t mind, and prefer the standard behavior.

2 – starts faster
3 – uses less ram

I agree that these are irrelevant on desktops and laptops today. Still an issue on handheld devices, though, on some of which at least vi is available.

4 – more comfort on other environments.

I don’t know about AIX, but on Sunos, Solaris, the BSDs, of course on Linux, the rescue environments are bound to have a standard vi… and you’re really not going to need all the features of vim (or emacs) to rescue your system (I hope).

5 – more productivity

I definitely found this to be the case when I switched from emacs to vim in 1989, and have never looked back. However, I was by no means an emacs guru.

6 – syntax highlighting

Sounds like bugs in the syntax highlighting scripts, not in vim itself. Perl and C syntax highlighting work great, for instance. I’ve rarely seen vim mess up on syntax highlighting, but maybe this is because I tend to program in languages that are easier to write syntax highlight scripts for (ie. ones that use curly brackets instead of whitespace to delimit blocks).

Also, when the default syntax highlighting scripts are deficient, there are sometimes alternative highlighting scripts available. I know that’s the case with Python. Check vim.org for more options.

7 – indentation

If you don’t vim’s default formatting options, you can easily have vim pipe your text through an external command (like par-format, or any of a thousand pretty-printers). If you’re really homesick for the way emacs does it, I bet you could even pipe it to an open instance of emacs and have it do it for you.. :)

8 – yank buffer managment

Check out the yankring script:

http://www.vim.org/scripts/script.php?script_id=1234

9 – problems moving between files/buffers

As many people have already pointed out, on this point you’re simply mistaken about how vim works. Also, there are a million scripts on vim.org that make file/buffer management much easier. Just browse through the most popular/downloaded scripts, and you’ll probably see half a dozen good ones on the first page.

However, even if you insisted on the default vim behavior, it’s really not difficult to remember that :bufn goes to the next buffer, and :bufp goes to the previous buffer. And if you manage to forget, there’s always :help buffers. All of these commands could be mapped to a single key or a short sequence of keystrokes, should you find occasionally typing :bufn or :bufp too burdensome.

10 – not being able to create a new top-level window

Using tabs is good enough for me 95% of the time. In the other 5% it’s really not a big deal to just open up another process. Still, this is an area where it wouldn’t hurt for vim to copy emacs.

11 – gqap

See above regarding piping the text through an external program, if you don’t like how vim’s formatting works by default. Personally, I want to keep any and all programs far away from reformatting my code, except to reindent a block here and there, which vim does just fine (in my experience). But if I need more, I’ll just pipe my code through a prettyprinter.

Finally, I’d like to invite you to #vim on freenode.org. There are lots of very experienced users and developers on there that can answer your questions and help make using vim a lot more pleasant. Also, check out vim.org for thousands of vim scripts and tips.

and turns out i found the following tip which probably solved the xml indentation problem you couldn’t find a solution:

http://vim.wikia.com/wiki/Format_your_xml_document_using_xmllint

this tip was created back in 2002, so maybe you missed it when you did your search?

In case you haven’t yet figured out, emacs has support for XFT font rendering backend. It’s still in CVS though. Some distros include CVS snapshots of emacs, I’ve been using one for some time and it’s been pretty good.

I’ve actually written a blog post about this a couple of weeks ago, take a look if you are interested (screenshot included!):
http://amrmostafa.org/bearable-emacs-recipe

I think you did not try long enough. However, I’m on the opposite trip now. I try (for the 2nd time, 1st try failed) using emacs to replace vim, now. Using it a few weeks I’m still much slower with emacs, but I agree to most of your points. I still think vi(m) is the fastest possible alternative if you just need an editor. But it’s beyond it’s capabilities to solve complex things as you can do with emacs.

The issue with comfortable typing isn’t so much keeping your fingers on the home row, it is reducing possibility for injury. The usage of control (or even caps lock) with your pinky is just too uncomfortable for me.

So even taking into account all the crazy stuff Emacs can do (I love and will miss dired), I just don’t want to permanently injure my wrists.

Thanks to all the people who reminded me of that!

I set Caps Lock to be an *extra* Ctrl key. If I want all-caps, I change the case after I’ve entered it, with gU(motion). Yes, that’s right, I’m using Vim, and I’d rather have an easy-to-reach Ctrl key than an easy to reach Escape key.

Why? Because ^[ is easy to type, and I *love* Vim’s completion. I know Emacs has M-/, but it’s not as good. In gVim 7, when something has multiple completions, it shows you a dropdown, so you can see how close you are to the one you want. And that’s not even getting into the ^X stuff…

Highlighting and indentation:

Which editor does these best varies between filetypes, but when Vim gets it wrong I don’t find it too troublesome. ^T and ^D fix indentation (as long as you’ve set shiftwidth appropriately), without leaving insert mode.

Your issue with deleting tabs it shouldn’t be inserting sounds like a misconfiguration. I don’t think I’ve run into it. If by “the insertion of Tab characters is disabled”, you mean you’ve set expandtab, then I don’t know how it’s happening.

Unfortunately, indentation doesn’t work in bird-style literate Haskell, ‘cos the arrowheads mustn’t be indented.

The paste buffer:

I like the way it works on the Mac version. The standard Mac clipboard keys (Command+X/C/V) use the “+ buffer, which is shared with other apps, and the standard Vim keys work the standard Vim way, and don’t interfere with other apps.

Multiple files:

I’ve got a mapping for “:ls<CR>:b<Space>”, which shows me a list of buffers, and I just enter the number of the one I want to switch to. I also use CTRL-^ a lot.

No multiple top-level windows:

Yeah. That’s my biggest gripe. I should have another look at the tabs feature sometime soon.

gqap:

I tend not to use that. Some of the files I edit have rather… idiosyncratic ideas of what constitutes a paragraph, so I just gqj, and then dot my way down. I tend to do that even when I think gqap would work, just because I like watching it.

@Adonikam Virgo, on bilingual files:

I have a mapping (actually a bunch of autocommands that remap the same thing) to switch between each pair of filetypes I want in one file. So it toggles between lhaskell and tex, for instance.

@troels, with the foreign keyboard.

So remap Ctrl+some foreign key.