Customer Reviews

Vi iMproved (VIM)

5 star:		(7)
4 star:		(6)
3 star:		(3)
2 star:		(1)
1 star:		(2)

 

 

I keep going back to this book again and again and that is one of it's strengths. It lays down a foundation of understanding, and then as you grow with the editor you go back to it to learn a little more about how you can customize your environment.

I particularly like the chapter 8 which covers abbreviations, keyboard mapping, and initialization files. It's well written and the effect is that I have saved a lot of time on my common workflows.

Upside, this book has made me a better Vim user. Downside is that the book could be even better than it is. The organization could be a bit stronger and there could be more expansive reference material. That being said. If you are a Vim user it is definitely worth the money.

I have used this book in a Windows environment; a few years of on-again-off again coding. I agree with the reviewer who found the book very disorganized. I am ordering the old edition of the O'Reilly book on the vi editor (a very small book, better than the newest edition and less than 5 bucks) because I found it more helpful than this book (!!).

I will try to go through it (yet) again, because I like vim, and recognize its power. I just downloaded TextPad and tried it for the first time in probably 4 years, and I am running back to vim after less than an hour of TextPad (the "dd" command of vim to delete a line has become essential to me :) ).

So, buy the book, but use the web and the excellent listserv to understand vim.

Vim is an exceedingly powerful, but somewhat esoteric text editor. You can make it do almost *anything*, provided you know how. I found this book to be indispensable in doing that, since it presents everything in an organized way.

This book does not replace a good google search or the online documentation. Instead its a great way to learn what Vim can do, and how to get about it. A must for any programmer's bookshelf.
Vi rules!

This book was the ticket to admission to the Linux world. To use Linux, one must immediately be competent with a text editor that runs on Linux. For me, a Windows developer who had used vi a decade or so ago on an HP-UX system but had successfully forgotten everything, this book allowed me to regain my vi-ish skills on Windows during my day job so I could productively goof around on Linux at night.

Other reviewers noted errors. To me, there were no big, hairy errors. This book yielded a positive learning experience. I shudder to think where I would be now without it. I had considered the purchase of a $... Linux version of a commercial editor that I use on Windows, but decided to give this book a try before I made the big investment. This proved to be a good decision, because now I eschew the expensive commercial editor and use vim as my text editor on Windows and Linux.

My only complaint with this situation is not with the book, but with me. Now, my fingers 'think' in vim, and those fingers 'think' much faster that my brain thinks. This works quite well when in vim, but not so well elsewhere...

One main reason people use vi/vim is that by using few key strokes you can do your editing job. In this book, author choose to teach you how to do things using the longest command available. For example, :split instead of :sp; :buffer instead of :b ...
It will be nice if author at least mentioned the alternative.

I had extremely high hopes for this book. I spend at least 12 hours a day using vim. My hope was that I'd learn a couple new things that would help me use vim more efficiently, or macros, or whatever.

Unfortunately, this book is really not written for an experienced vim user. It is written for somebody who is scared of vi in general and needs a book to start with. The author goes over such mundane details as "how to get out of insert mode" to a horrifying degree.

I didn't really learn anything reading this book. Vim comes with exceptional documentation, and this book seems to be nothing more than a digestion of that documentation.

I really would recommend against this book for all but the very new-to-unix user.

Oh, and the occasional commentary throughout the book about how unix vim isnt "smart enough" to do something the windows vim does just made me sick.

I haven't read this book but am considering buying it. What I don't like is seeing some review that gives the book one star just because it was hard to do something. It took the guy "20 minutes" to figure it out. Some men would look at the source code if they didn't know how to do something in vi not read some book. You should be greatful to the author for writing this book because you aren't reading the sourcecode, you aren't even reading the man page.

This book is poorly structured, for example, as a newbie I tried to figure out how I could insert a file into my current buffer... simple operation, yet with this book it took me 20 minutes before I literally stumbled accross the appropriate place in the book. This book is not organized well and it hurts. Further, the author doesn't explain VI concepts well at all. The reference part is just as dis-oraganized as the rest... just try to find what you are looking for. What made me write this review is that I just wasted another 10 minutes looking for how I can have two buffers open (but not two windows) Anyway, I've given up on this book ... perhaps I can get a refund? Any other suggestions?

I've been a vi/vim user on and off for the past 3 years at school and whenever I was accessing a server on the production floor. I've gotten by with basic editting commands but I wanted to learn some of the more advanced features that vim offers.

This book has been invaluable as a rough learning tool and a quick reference. Provided I actually know that a feature exists, I've been able to find the right syntax for it within a few minutes of flipping through the index/table of contents.

As a result, I'm now more or less a consistent vim user on both Linux and Windows platforms.

If you've ever wanted to know vim in more detail, then this book will be a good help.

I decided to learn Vim because I work on WinNT/2K, Linux, and Macintosh boxes. Using a single editor makes it easier to work on mulitple platforms.

My review of this book is mixed. First, it's the only book on Vim and it contains a lot of information, so that's a plus. Also, it shed a lot of light on using the editor that, frankly, the help files did not (you can look up *ANYTHING* via ":help <topic>", but the documentation is not very accessible to the new user). However, the typos, errors, bad grammar, and personal idiosyncracies of Mr. Oualline just have to be seen to be believed.

You can figure out most of the errors easily enough. For example, there's a reference to the non-BUI version of Vim (I think he meant GUI)and for some reason, in the word "filename", when used as an example (e.g., "type 'vim filename'"), the "fi" is sans-serif while the rest of the example text is in bold Courier. There are, however, numerous places where the diagrams don't match the example being discussed in the text or are just plain wrong. Some of these left me wondering if I had missed something, but trying out a command in Vim quickly showed the diagram was wrong. My favorite goof is where '#' (the command to search backwards for the word under the cursor) is shown in numerous places in Appendix C (pp. 445, 449, and elsewhere) as a British money sign (e.g., "/count/ L"), where L is the pound sign. Get it? Pound sign? Obviously the person who did the Appendices and Index (and copy-editing???) was not Mr. Oualline.

With regard to the content, I found that Mr. Oualline is very idiosyncratic. Vim is VERY flexible, using ancient Vi ways of doing things, as well as more modern ways that are easier to use. Take yanking (copying) a block of text to a register (like the clipboard). *Mouse way*: select lines, press y. *Visual way*: move cursor to top of lines to be selected, press V, select lines, press y. *Vi-ish way*: go to top of lines to be selected, press "ma" to drop a mark labeled "a", go to bottom of lines, type y'a (yank from current position to mark "a").

If you consider these different styles (mouse, visual, or Vi-ish) to approaching the same general problem, Mr. Oualline always goes with the Vi-ish style, to the point of also showing you in many cases how to precede the command with a line range instead of using marks. Where Ctrl-Wn (open a new window) will do, we get Ctrl-W Ctrl-N (equivalent). Where Ctrl-W<down> moves down one window, we get Ctrl-W Ctrl-J (the arrows aren't mentioned). My guess is that this is not how the majority of new users will use Vim (though it might be handy if you find yourself using Vi or Vim via telnet).

A real barrier to learning the editor is the immense number of variations for accomplishing a given task. Multiple keystrokes to accomplish the same thing, as well as different approaches. What would be great for Vim is an attempt to break down tasks into functional groupings (movement, formatting, programmer stuff, managing buffers/windows) and choose a style (probably visual mode, which is almost interchangeable with mouseing) so you can say "here's a good way to get started." The many variations can be left as an excercise for power users. They are available in the online help, anyway.

All in all, I learned a lot about Vim from this book. But if I hadn't been determined to do so, I would have given up. If you want to learn Vim and the online docs aren't doing it for you, buy this book. You've been warned, so just chuckle when you come across errors and general weirdness. Kudos to Mr. Oualline for writing a book, but don't give up your day job. :-) BIG raspberries to New Riders for letting this slip through without proper editing. And thanks to Bram, who put up an unofficial list of errata at www.vim.org.