I’d been using Emacs for quite awhile, and about 8 months ago I decided I would try using Vim. I’d only used vi for system emergency work, but knew a number of people that swore by it for regular work. So I decided I would learn Vim and use it for my regular work. I figure that with things like this, I don’t get a real feel for how well they work unless I use them for all my work. So I haven’t really opened Emacs at all in the past 8 months.

Yesterday I finally decided that Vim was not living up to my expectations and I’m in the process of switching back to Emacs. I thought I ought to write down why I’m doing that, for my own future reference… and since nobody has ever written about Emacs vs. Vim, I might as well post it where everyone can see it.

So here we are.

Original Reasons for Using Vim

It would lead to more comfortable typing. Lots of Vim users mention that you don’t have to hold down keys while hitting other keys as much in Vim as in Emacs, and that the movement keys are all on the home row. That’s true, but I didn’t find it to be that big of an improvement, since Esc is a farther reach than anything in Emacs, and let me tell you, you’re hitting Esc all the time in Vim. I found that removing the armrests from my chair made my hands happier than Vim ever did, and swapping Ctrl and CapsLock in Emacs will probably help there too.

It starts faster. I’m not sure if that really was true even when I switched, but it certainly isn’t true on any of my machines today. Both Vim and Emacs have had major version upgrades (v7 and v22, respectively) since I started using Vim. People seem to say that Emacs 22 feels faster, though I don’t know if that’s true. The startup times of the two, if they’re different, are imperceptible.

Vim would use less RAM. Frankly, these days, both Emacs and Vim are way down on the list of things that use up RAM. Heck, kmail has 141MB resident, and each of its two IMAP processes is using more than 30MB. Emacs in X right after start has 16MB resident, 10MB of which is shared, and 25MB VSS. gvim right after start has 8MB resident, 5MB of which is shared, and a 43MB VSS. Emacs tends to use fewer processes for things that vim. So they’re not all that different, and Emacs could come out smaller in certain situations. But the difference is irrelevant on today’s machines, and modern Gnome and KDE apps are many times larger than both of them.

It will make me more comfortable in rescue environments where I have only traditional vi available. Actually, the vi on AIX is so different from modern Vim that this didn’t really help.

It would make me more productive. There are some editing commands that did, but as you’ll see below, it was more than balanced out by other problems.

Things I Liked about Vim

The commands dt, dT, df, dF. Wonderful little things those. Emacs now has M-z (Zap), which is similar to df but can actually go to other lines (a nice addition). And there are easy ways to bind keys to the others as well, though that doesn’t make it a pervasive convention like it is in Vim.

Antialiased fonts. It’s crazy that Emacs doesn’t have this yet. But not a showstopper; I still like good ole 10×20 just fine.

Regexp search-and-replace. Emacs actually has this now, and maybe it had it back then too. M-C-%. Apparently in Emacs22 the replacement expression can also have lisp code in it, which sounds really slick but I can’t see myself using it regularly.

Annoying Things in Vim

Syntax highlighting. The syntax highlighting for most languages in Vim felt like it was about as smart as it was in Emacs about 10 years ago. Strings like "Hello!\"" (in languages where \” inserts a literal “) often confused it. Sometimes quotes within comments confused it. Sometimes it would be confused permanently. Other times, just until I scrolled around in the file or reloaded it.

Indentation. This is much more annoying than the syntax highlighting, really. In many languages — and especially the two modes I’ve used most recently, XML and Haskell — it really, really stinks. The indentation there isn’t aware of syntax, or not very much. Sometimes it is smart enough to know that if an XML line starts with that it moves left and if it starts with an opening tag, that the next line moves right. But it’s not smart enough to do this reliably. Not only that, but indentation is not handled with consistent configuration between languages. And even though Vim ships with a ton of language modes, the central docs only cover indentation for C.

I’ve asked Vim experts about this, and have tried all sorts of various tweaks, have read through Vim indentation mode source files, etc. There is just no way to get it anywhere near the intelligence of Emacs for most languages, short of writing my own mode, it appears. This is even worse because when using the backspace key in insert mode, for awhile it deletes individual spaces, and then all of a sudden deletes a big chunk of whitespace back to the beginning of the line. (And no, the insertion of Tab characters is disabled.) Indentation is my #1 complaint about Vim, and something that shows no progress towards being fixed any time soon.

And forget about anything like Emacs M-x reindent-region. This is a syntax-aware indenter. You can write out an entire source file with no indentation whatsoever, and it will indent the entire thing according to the indentation rules you’ve defined and the syntax of the language you’re using. The best I’ve seen in Vim are commands that add or remove space at the beginning of every line in a region.

In short, Emacs seems to “understand” the file format on a much deeper level than Vim, and can automate things to a much better extent because of it.

Too many things disrupt the paste buffer. I can use Y or y to yank some text in Vim, and it’s really, really easy to overwrite that buffer with other things. Yes, I know that I can yank it into a named buffer, but that’s inconvenient and I don’t usually know in advance that I’ll have that need. In Emacs, only C-k and other “large area” commands disrupt it.

Vim doesn’t like you having lots of files open at once. It’s surprisingly convoluted to do this. If you use the basic documented command to edit another file, :e, it closes the file you’re working on. The normal way to open multiple files at once is to use split windows. Well, I don’t like split windows all that well, and often just want to make a quick change in one file — in full screen — and then go back to another. Even though I use set hidden in my ~/.vimrc, it still is annoying and more convoluted than it should be.

Vim can’t create new top-level X windows. In Emacs, I can press C-x 5 2, and poof, I have a second Emacs window in X, and it’s tied to the same editing session and Emacs process. Not a new process, with a different set of files, its own buffers, etc. The same process, same set of files. Just like a split window, but with a new top-level X window instead. gvim simply has no way to do that. This is also a large annoyance.

gqap stinks. This has burned me more than once. I’ll be editing an XML document, and insert some text in the middle of a paragraph. Now I have a really wide line. So I type gqap to reformat the paragraph. My cursor is near the bottom of the screen, so I don’t really see much past the current line. I then save the document and exit. Later I discover that vim considered the entire rest of the document part of the single paragraph, and removed all the different indentation levels at and the like, so it’s completely messed up. Emacs is smart enough to know what is a paragraph in XML mode, and M-q does the right thing. Oh, and Emacs reindent-region can fix the Vim gqap-induced mess.

I tried
print “Hello\””
in a python file…
and that worked just great. It’s ‘always’ worked as far as I know.

Vim will do different sorts of syntax highlighting based on whqat type of file your dealing with.

If I just open up a file with no extension or anything like that, just plain text, then syntax highlighting obviously doesn’t work with the “hello\”” example.

By default a lot of Vim’s mode-detection stuff is disabled. Maybe that’s the issue.

Then with the autoindention stuff.. it’s brilliant.

Many many times I’d be editing a file or something like that and all of a sudden the ‘auto indent’ seemed to go all funky on my ass. It didn’t work, it did stange things… Then I examined the source code and realised that I had missed a ) or a : or something important like that, and that the auto indent was the one acting correctly while I wasn’t.

I thought it was odd that you’d complain about this since both the highlighting and auto indent worked so well for me.

Although this is all using python mode. I am more then willing to accept that there is large variations in quality between different language’s syntax support.

What was your issue with using multiple buffers with “set hidden”? I don’t know of any criticial distinction between using hidden mode (which should be the default IMO) in Vim and managing multiple buffers in Emacs — to me they are functionally equivalent. Personally, I never use split windows. You may find one of these filesystem/buffer management plugins useful:

I can’t be certain, because I sorta gave up on it awhile back and just used multiple gvim instances, but I THINK these were the issues:

:n, to access the next file given on the command line, still wanted to close the current file. ISTR that :e didn’t do the expected thing either, but I think there was some 4-character command that did what I wanted, but could never remember.

I don’t think these commands behave this way, at least in my configuration — however, I can certainly understand being frustrated with the awkward :e, :n, :prev, :b* interface.

If you feel like giving Vim another shot in the future, I do recommend one of the above plugins (or one of the many other similar plugins). They provide much more “emacsy” buffer management, very similar to find-file and iswitchb-mode. (Which are simply better than what Vim has to offer in a plain install.)

Hey – I understand your frustration with the buffer thing in vim. Long time back though I discovered the following mappings and stuck them in my .vimrc:

nnoremap :bnext
nnoremap :bprevious

Then you can essentially hit “Ctrl-Tab” and “Ctrl-Shift-Tab” to switch between buffers. So if you’re editing one and need to do something quick in the other just “:e other_file.txt” as suggested, edit it and then hit “Ctrl-Tab” to go back (or better yet, if you’re really done with it hit “:bd” to delete the buffer you just opened since you’re now done with it).

Also, in Vim 7+ try “:tabe” which opens up a file in a new tab. Then “gt” or “gT” switches forward and back (respectively) between tabs.

I actually like that buffers have to be saved before moving on. It stops a whole class of mistakes that I could make while editing multiple files. You can have files saved automatically by using the ‘autowrite’ and ‘autowriteall’ config options.

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.

It may be that Vim’s Python mode is as good as the Python mode in Emacs, but I just didn’t do much Python work during the time I used Vim. The modes I did use regularly were certainly not as good as the ones in Emacs. What you describe for Vim’s Python mode sounds like what I expect out of every language in Emacs, including markup languages and other more obscure ones. Quite frankly, I expected it out of Vim going into the project too, and was disappointed to discover that the Vim modes were not consistently high-quality.

Perhaps I’m just not understanding what you want to do, but :e in vim will just open a new buffer with the new file in it. The old buffer is still there (:buffers to display all buffers). You can switch buffers at any time, no split required. In vim splits and buffers are orthogonal. You can have multiple split panes open on a single buffer, or have each pane be a view on a separate buffer.

The *biggest* problem is the indentation in Haskell and XML. I have searched extensively for solutions to that. Yes, I *could* write my own, but learning how to do that — and getting it done right — would wipe out any productivity gains I’d get from using vim for maybe the next couple of years or more. Not worth it to me, when Emacs has working indent modes for every language I try.

I have tried to avoid using too many nonstandard plugins, both in vim and emacs. Hard to maintain when you work on lots of machines, may not be updated when vim is, etc. I did use the nonstandard Haskell mode in vim, which helped, but I believe I limited myself to that. I use the Debian haskell-mode package in Emacs. (I don’t mind them if they’re in Debian packages, because then they can be kept up-to-date automatically)

So yes, I accept that plugins could help some of this. But not the biggest pain.

Defense network computers. New… powerful… hooked into everything, trusted to run it all. They say it got smart, a new order of intelligence. Then it saw all people as a threat, not just the ones on the other side. Decided our fate in a microsecond: extermination.

I agree with all of the problems listed with vim. As has already been said, the flexibility is there to fix some things quickly. Unfortunately at the point when it comes to the scripts which control syntax and indentation the learning curve is undefined.

I am currently working mostly in Java, XML and PHP. Though I have hacked a solution together to syntax-highlight PHP and XML in the same document and find the indentation sufficient for my purposes, I frequently find myself working around the automatic indentation. Though I must admit the temptation to “give up” is real, the religious fervour in me assures me that a few more lines in ~/.vimrc will solve all my problems, if only I could find the right tip. Perhaps someone needs to contact the xml.vim maintainers and get it fixed once and for all!

When I worked in Haskell last year, I do not remember having smart indentation on at the time, and I was only writing small programs, so I was quite comfortable. However, the popularity of the language is such that I concede that it may be a long time before an intelligent indentation script is written, unless a friendly emacs convert comes and helps out. :)

I’m a hardcore Vim user, and it’s true, Vim doesn’t understand the syntax of most languages at a deep level. I think that’s because the vim script/configuration language isn’t really all that powerful, and its easier to parse in elisp. Lisp in general is pretty good at that stuff. As a consequence, syntax highlighting is alright, basically just all the keywords and not much more. Indentation also sucks for languages like Haskell with subtle indentation patterns. Python is simple, do a new indent on lines after a line ending in :. Vim also has good indentation for Scheme/Lisp, which are also pretty easy to parse.

I think your other complaints are fixable, but I agree that the above is a real fault in Vim.

I know that vim should probably take things into account, but if the language has a difficult syntax to highlight, then that language has a problem. Vim should do it yes, fine. I found that finding which option to change to simply activate fontlock, (which apparently means syntax highlighting) for emacs far to annoying. To me, vim has a short learning curve. With emacs, there’s so much crap, it’s hard to tell what it is you want to know.

Re: autoindent, I’m a long time Emacs user but I really miss vi-style dumb, non-syntax aware autoindent every time I end up using a less than polished language mode. I have my own set of functions to do sorta kinda the same thing, but they aren’t really good enough, at least yet, to publish.

Indentation works in vim for everything but Haskell. Have you tried :filetype indent on yet?

I’ve been a former Emacs user myself, changed to vim a year ago after my RSI… it *helped*!
But, to be serious, both suck. Vim’s major flaws are: it’s folding is just plain broken. It just doesn’t work reliably. And using this half-hearted vimscript thing as a backend was a wrong decision. Having a complete language to back your editor configs up (like emacs) would be waaaay better.

One *very* nice thing about vim is the eclim-plugin – vim-integration to eclipse! Yay!

One thing, which really set me off, using vim is, that I’m using a non-US keyboard. For regular characters, things are the same, but specialchars are placed at different locations, some require pressing Alt Gr. This means that a lot of the standard commands (For example, pressing Ctrl+[ is rather awkward) aren’t as “home-row” as they are sold as.

Use US international when programming. Most international keyboards are inefficient to program with (I’m used to norwegian). With US intl. you get all special keys with alt+gr, like æøå, and have easy access to [] and the like.

M-x viper. I can’t imagine (well, I can but I won’t) using emacs without it. I switched from gvim because the installation I had to use at that time crashed once too often, and I gave emacs a chance. But not without the vi emulation.

Since vim 7, you can use :tabnew (and other assorted commands) to open up new tabs, each of which can have multiple windows. Map this to keys, and you have a much better way of working with multiple files at once.

And :e does *not* close the previous file. That file is still in a buffer, and you can switch between buffers using :b#

I think you need to spend a little more time with the vim tutorial – as the previous commenter mentioned – :e doesn’t close the previous file.
The messing with the paste buffer thing is totally true though.
Personally I think it really depends on what you’re looking to do and how familiar you are with Unix systems. I think this site breaks it down nicely: http://comparati.com/1084-vi-vs-Emacs

Basically – have some time to spare, and know Unix well? Use Vim. Else – Emacs.

I actually just went the other way – from emacs to vim. I found emacs tabbing to be completely insane, and I was never able to find a solution. I LOVE how vim handles tabs. It’s indentation is excellent.

I’m using these, which I think did the trick:
set smarttab
set cindent

I’ve been considering making the switch to Vim due to peer pressure, and was about to make the leap next week. But I was procrastinating due to a suspicion that Vim would suck at Haskell. Thank you, you’ve saved me from much wasted time in VimLand.

A quick note from a vim user — I won’t defend it where I know its shortcomings. I know that indentation and gq suck. But I still prefer it because it’s very efficient, and no, I never touch the damned Escape key. (Not that it’d be practicable either, as in my xterm, there is a slight delay before it takes, because Esc is the same as a Meta- prefix to it). I just use C-c. It’s very fast and my hands hardly move in a vim editing session. It behaves like Esc in all but one case that I know of (multi-line insertion, which I think emacs doesn’t have, incidentally), but you can easily remap it in your vimrc.

I use vim because it’s the most programmatic text editor, the one that best combines a user interface with a simple rule language, and it’s thus naturally suited to writing code. Even despite the indentation.

By the way, you are incorrect, there is actually a way of re-indenting a document (just gg=G, no colon), but the indentation is definitely less polished than in emacs for most of the new-fangled languages.

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.

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.

I see that you noted comfortable typing as a pro in Vim’s column. That is basically what is forcing me to move over to Emacs. I haven’t even tried Vim, but I know if Vim doesn’t work out then I’ll just have to use an IDE.

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.

On my first Unix course several years ago I was told it will take up to two years to learn vi properly and effectively. Strange stuff I thought, but I now know that was true. I think I’m quite fast in vim now and using something different wastes up extra time always.

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.

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.

﻿It sounds like most of the problems you have vim are from lack of familiarity.

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

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.

I may be confused, but I just read the manual and it sounds like without :set hidden (which is NOT default) Vim definitely CLOSES files when you leave them. It maintains a buffer list of where you were, but unless you :set hidden it unloads the file. If you have unsaved changes it asked you to save them etc (again unless you :set hidden). You can especially notice this with netrw files (open a file over scp etc) it takes time to go back to the file without :set hidden and with it it’s instant.

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.

Meh, I use Vim for Perl and Javascript programming and aside from very rare single ‘ issues, syntax highlighting and indentation is never a problem… V and > are nice for indenting blocks of code, autoindent rocks!! and it you need to turn it off :set paste! is easy enough to type to shut off the indentation. when I can Vyp and :s/oldtext/newtext/ to copy lines of text, who needs anything else. :D I use Vim with Screen so all most of the Emacs keystrokes clash with my bindings so… that’s that.

I wonder which key combinations clashed screen and Emacs. If screen cmd key(Ctrl-A) bothered, I wonder why it didn’t bother you in bash.
But, I use ‘screen -e^Zz’ since I rarely stop my process and free up Ctrl-A.

You complain of having to reach for all the
time , but it is easy to not have to do that — just use
“imap”(key re-mapping for insert mode) to map a sequence of two keys(eg “fg”) to . It is easy to learn to type that two key sequence rapidly enough to trigger the invocation of .

I just sent you a comment that got mangled.
Try it again. You complain of having to reach for the ESC key in vim , but it is easy not to have to do
that. Just use “imap” (key re-mapping in insert mode) to map a sequence of two keys(eg “fg”) to
ESC. It is easy to learn to type that sequence of two keys rapidly enough to trigger the invocation of
ESC.
I love both vi and emacs. A blessing on both
their houses.

I will agree that there are things in vim that I do not like. I absolutely refuse to run vim in vi compatible mode. Using keys to move my cursor around is just so strange to me and really a little used feature since the arrow keys are available on 99% of the keyboards out there. However where VIM shines the most over emacs is in a X windows environment. GVIM really looks like a gui program emacs looks like you started it from a xterm. I agree that each one has its uses and its really a personal preference on what to use. I personally don’t like either one very much. I would prefer a simpler text editor as I rarely use any of the “advanced” features that emacs and vim offer. I know there is nano but I have never really warmed up to nano either.

As you get used to working in Vim normal mode, you’re not supposed to use either arrow keys or hjkl most of the time. You instead navigate a word at the time with w/b or W/B, a sentence at the time with ( and ), a paragraph at the time with { and }, or until next occurence of character ‘x’ with fx / Fx. See `:help cursor-motions’ for more info.

I used vim for probably one and a half years. It’s a great editor, and I really like the movement keys and chainable commands. However, after switching to Emacs for three months, I’ve begun to notice every one of those weaknesses of vim a lot more. Especially the one where your main register was so easy to be overwritten, that got me all of the time.

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?

Hey! EVERYBODY posts about Vim and Emacs! It’s always on! You’re not the first one.

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!

Agree with many of your comments. I have been using Vim (and continue to us) for over a year. The syntax and indenting needs work. It’s adequate not good. I basically turned of indenting for HTML.

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.

There is a learning curve for the syntax highlighting.
I’ve made a couple of simple ones for myself but haven’t tried harder.
I haven’t noticed any problems with the HTML highlighting and I do use it a lot.
With some other types they are sometimes documented as not covering specific complex parsing situations but that hasn’t troubled me.

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?

I digg Vim and Emacs. Both are great editors. Both do things differently. Emacs is a badass because you could just open a shell right there and reboot your unix webserver, then bounce back to your file you’re editing. Vim/Vi is good for editing files, system rescue/configuration. I sometimes even use Nano if I don’t feel like hammering the ctrl key or using command mode in Vim. Pretty much depends on what mood I’m in/what I’m doing.

I’ve been using vim for about a year now, since I finally found myself on a workstation where I really *had* to edit files over a console. And I found it pretty nice, but I have thought about switching to emacs, but never really took the dive.

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 was an Emacs-only user for about something less than 10 years. That was before my left little finger got injured (due to heavy use of Emacs in my daily professional programming life). I had to switch to vim. My finger was saved. I still do use Emacs just for debugging.

When I first started using Linux I learned Vim. I had wanted to learn Emacs but something just wasn’t clicking about it–which was odd considering that Emacs is usually considered to be less intuitive.

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.

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

“since Esc is a farther reach than anything in Emacs, and let me tell you, you’re hitting Esc all the time in Vim.”

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.

I think that both emacs and vim are damn good and powerfull editors, and both are good to the extent ones knows how to use their features. Aside from that, it is natural that some will feel more confortable with one and less with the other. We are different. :)

I think your arguments are not that great. For example, you think that the only way to exit insert mode is to hit . You can map the key to do that for you.

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.

I have been using both vi and emacs for more than 20 years, so the difficulty of learning, the choice of keys and most other issues discussed here are no longer important. Until recently, I had been doing most of my work in emacs, using vi as a sidekick, often doing bizarre things like editing my .emacs. Don’t laugh; it is simply easier to type ‘vi ~/.emacs’ than ‘c-x c-f ~/.emacs’. Sometimes my choice of the editor is totally random. They are basically equivalent.

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.

[…] However, as much as I liked vim, I did have a number of things about it that really bothered me. First and foremost is vimscript. To me it just feels really half baked and extremely domain specific. If I’m going to have to learn/use a language to configure my editor, at least make it a cool one like lisp that can actually be used elsewhere. While you can configure vim using other languages, as this post indicates, it is not without its pitfalls. Also, I found myself agreeing with posts like this. […]

I think several of your arguments are not really relevant:
– About the RAM : since in fact, it does not have any impact on a desktop personal computer, it does when you share a network development machine with several developers. We got this problem in my team about emacs.
– About the fonts : I dont know how you use emacs but when I use it, wether from Windows in putty or on linux in a terminal, I do have anti-aliased fonts, because it depends on the terminal, not the editor.
– Top level X Windows : Same thing. Gvim is awful, small wonder it doesnt fit your needs. To enjoy a real vim experience, Xterm or Gnome terminal will do nice.

When I first started using vim, it felt claustrophobic and slow and difficult to use. After a while I realized that this was because I was using the arrow keys too much, and I realized that I was doing that because I would use them to move around in insert mode, because esc was way too far away. To fix this, I disabled the arrow keys, and I mapped esc to jk. From that moment on, everything felt immensely easier and faster and more powerful. Nowadays I can’t imagine using any other editor. Yeah, some things in vim are pretty broken by default, but those are all things that can be fixed with some minor configuration, or a plugin.

For example, when I first started with vim, I opened a new tab for each of my documents, as I would in graphical editors. This got annoying really quickly, because you can only have so many tabs open at a time. It’s the same issue with splitting the window. So I did some research, and I found out that I was using tabs and splits wrong. I figured out what buffers were, and how to switch between them in the same window, and I set hidden so I could hide documents with unsaved changes. After a while, this also got annoying, because vim’s buffer switching is kind of atrocious. So I did some more research, and I found probably the most useful plugin I’ve ever seen: ctrlp. This plugin gives you a scrollable list and fuzzy search so you can jump to just about anywhere. You can use it to open files, hidden buffers, recently closed buffers, you can jump to tags, whatever you want. I have ctrlp open in file mode when I press ctrl-o, and in buffer mode when I press ctrl-p. I just hit the shortcut, type bits of the filename that I want (and maybe arrow up a bit), and when it’s selected I hit enter. And it selects the last opened file by default, so if you go somewhere to make a quick change, when you want to go back you don’t have to type anything, it’s already selected.

I had a few issues with indentation, but I’ve fixed most of them through various configurations and plugins. I’m trying to fix Haskell indentation at the moment (that’s actually what I was googling when I found this article) and I’m sure there’s a good plugin somewhere for it. I think they fixed syntax highlighting for the most part by now, I’ve only seen it get confused a couple of times, and the files that happened with were written in some more obscure languages that I would expect aren’t supported quite as well as the common ones.

“And forget about anything like Emacs M-x reindent-region. This is a syntax-aware indenter. You can write out an entire source file with no indentation whatsoever, and it will indent the entire thing according to the indentation rules you’ve defined and the syntax of the language you’re using.”
In vim, this is the ‘=’ key. So ‘gg=G’ to properly indent the entire file, ‘=ap’ for the current paragraph, ‘==’ for the current line, etc.

“Yes, I know that I can yank it into a named buffer, but that’s inconvenient and I don’t usually know in advance that I’ll have that need.”
You can put from a buffer number. Vim saves the last ten yanks, so if you need an older one you can just check which number it’s in and use that as the buffer name.

“Vim can’t create new top-level X windows.”
… I can’t imagine why anyone would ever want this. If I wanted multiple top-level windows I would just use MS Notepad. Window splits work fine. I guess if you wanted to keep your splits the way they are, and open a new window with different splits for other files, that would make sense … but then, just use tabs. That’s what they’re for.

“gqap stinks.”
Vim has a very particular definition of what a paragraph is. If you don’t want to wrap a vim paragraph, use a different gq command.