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 </para> 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.
Vim can do [b]dt[/b] across lines: use [b]d/c[/b] to delete to the next character c. (And of course this can delete to an arbitrary pattern rather than just a single character like [b]dt[/b].)
I pretty much agree with the rest.
Ben.
Right, the whole
I donno.
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:
LustyExplorer — [url]http://www.vim.org/scripts/script.php?script_id=1890[/url]
fuzzyfinder — [url]http://www.vim.org/scripts/script.php?script_id=1984[/url]
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 :bprevious
nnoremap
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 stand corrected. I have checked, and :e behaves as you stated under set hidden.
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.
With autoindent on, =[range] will reindent based on the language. I often wind up using =% to reindent a function after I’ve refactored it.
Well, if you have something like this in Python it does not work:
def test():
print “hello”
if a ==b:
pass
else:
pass
That’s because python syntax is _defined_ by indentation, so the indentation can obviously not be defined by the syntax. We’ve got a classic chicken-and-egg problem.
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.
Actually, I stand corrected here. In the example I gave, my newest version of Vim is doing the correct thing, while Emacs doesn’t!
On hitting Esc — have you tried Ctrl-[? This can be really quite convenient if you remap CapsLock to Ctrl, as your hand doesn’t even need to leave the home row.
On opening many files — have you tried :tabnew or :tabedit?
On formatting with gq — paragraphs are defined in a strange way in Vim; all consecutive non-blank lines are in a paragraph. If you just want to reformat the line, you could use gqq instead.
Lots of love, and have fun back in emacs,
~d
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.
Check the vim manual.. :e really closes the current buffer. It may remember where you were, but it wants you to save before switching. I want to have multiple ones open at the same time.
Hi John, that is only the case if you are not using “set hidden”. For anyone using Vim as a development environment, this is pretty much a mandatory option.
You bailed on vim too early. Vim is kind of like Spider-man. Only with Spider-man the qualifier is responsibility, with vim it’s a steep learning curve.
Your complaints seem to be that vim doesn’t work for you out of the box. That’s not a reason to dump it. Vim is infinitely customizable, but it just takes time to figure out how.
For example, the Minibufexplorer plugin solves two of your problems.
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.
There are various scripts to keep your VIM runtime up to date. Also, using the VCS of your choice to keep your RC files in one handy bundle should be pretty much standard, these days :)
Emacs 23 will have antialised fonts.
Ubuntu packages for CVS version available here:
http://peadrop.com/blog/2007/09/17/pretty-emacs-reloaded/
Emacs 24 will run Skynet.
What is Skynet? Google turned up a bunch of hits, but none seemed relevant.
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.
To see it in action, watch any of the Terminator films…
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. :)
Yeow, Zing! ;-)
Actually, Python borrows heavily from Haskell syntax in a lot of ways. I wonder if someone hacked up the Python mode a bit…
When you open a file with :e it doesn’t close the file you’re working on. It keeps it in a buffer. You can switch back and forth between full screen opened files with :bn, :bp, :b or :b
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.
Yesterday’s post about switching back to Emacs saw quite a few comments from people (most of them useful, even). I learned a few things.
My biggest gripe about Vim was that for the file types I worked with most, its indentation and syntax highlighting
NEVER USE ESC !
Use the ctrl+c instead !
Or use Control-[ instead if you really need to press escape.
there are slight differences between Control-C and Control-[
What the hell are you guys talking about? Is it really that bad? Can’t programmers google anymore? Swap Caps and Escape insensitive clods. Here’s the xmodmap to do that:
! swap caps and escape
remove Lock = Caps_Lock
keysym Escape = Caps_Lock
keysym Caps_Lock = Escape
add Lock = Caps_Lock
You can do the same thing for the linux console with this:
keycode 1 = Caps_Lock
keycode 58 = Escape
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.
Oh, and as mentioned, Emacs 23 has smooth fonts. Highly recommended.
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#
Cheers.
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.
Did you get to try M-x viper-mode ? Best of both worlds IMHO
You can C-c instead of Esc, too.
Swapping escape with CapsLock is a must for vim. Try it, you’ll never go back.
Hello. Though I haven’t read all of what you wrote yet, I’d just like to say that Control-[ has the same function as Esc in gVim.
Automatic indentation of blocks can be done with the visual marking and the == command.
I have this line in my .vimrc because I tend to use it quite much:
map ==
I do agree with the paste buffer thingy though. Although I’ve gotten quite used to it after a couple of years of Vim abu… use. :)
VIM sucks……….
Emacs Rocks…..
CTRL-6 (or CTRL-^) switches between buffers.
And you can switch a particular buffer by typing the number of the buffer first.
eg. 3 CTRL-6 for the 3rd buffer.
:ls
lists open buffers
I agree and understand most of your criticism, except (as already mentioned by others) the :e behavior.
I would like to mention, though, that I didn’t really become comfortable with vim until after 3 years or more, and now after 7 years, I am very comfortable.
Some of the things you mention, like hitting the esc key a lot, is something that goes away.
Other than that, your article inspired me to try and give emacs a shot again – I doubt I’d change, but I think I’ll give it a shot like you gave vim, and see if the migration the other way is easier.
Thanks for a good article.
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 have to admit that I gave up on EMACS in the same way as I originally gave up on vi.
I really like the navigation with vim/vi, the issue is being able to use it everywhere.
At the moment I am using visual studio a lot and ViEmu is a great help since it allows me to stick with some of vim, and use the IDE.
And your point about the syntax and indenting is spot on for c# and SQL files. However gg=G works great under ViEmu at sorting out the mess, and vim is better than Visual studio on SQL.
Regarding program size etc. vi is still much better than vim and the only thing in my view for massive files.
Going to try out EMACS again in viper mode.
Thanks for a sensible debate!
Just installed emacs and tried it out on re-indenting some SQL.
WHAT A NIGHTMARE!!!
It was a complete joke just kept shifting to the right and never came back.
vim is much better for SQL, but still has some nasty bugs.
However, It is probable that if I had a clue about emacs it will be possible.
The SQL integrated editor in emacs looks really nice. Not managed to get it working yet. The vim plugin had a much worse UI, but did connect to the database.
Looks like this could take a while. However viper does reduce the learning curve drastically.
Since gg=G worked to reformat the code. It was a total mess so I researched found. C-x h C-M-\ and got the same mess.
Vim took the mess and sorted it back out again, and worked with the original file.
However using viper and C-z to switch between normal and emacs mode is nicer than using esc, and emacs is a lot prettier.
:)
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.
There is another way to do Esc. CTRL+[. Sometimes it’s faster than ESC up in the corner :D.
Comfort of typing:
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.
Okay, I’ve started using tabs now. I don’t know why I wasn’t before. Now the lack of multiple top-level windows doesn’t bother me any more.
Thanks to all the people who reminded me of that!
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.
It’s not as powerful as dired, but try :Sex in vim.
I’m sorry, I meant move over *from Emacs.
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.
Ah, nice post. I’ve recently switched from vim to 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.
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 saw your post when i was googling the xml indentation issues in vim.
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?
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.. :)
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.
Oops, I meant :bnext and :bprev (or :bp and :bn for short)… this is what happens when you rely on scripts like Buffer Explorer a bit too much :)
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.
By the by, GNU emacs, at the very least, could perform regex-based search and replaces since 1987. I suspect this feature existed much earlier. But, proof only comes from one of my old manuals. :-)
Bill
As an emacs user gone vim (2 years ago), I don’t think you gave vim enough of a chance. However, that’s why we have options, use what suits you best.