Slashdot Mirror
Vi IMproved -- Vim
Learning to crawl
Books describing editors generally fall into two categories. The first category of books will describe a particular function (like moving through a file) with all the known ways for performing that function, ad nauseum. The second category distills the myriad of ways to perform that function into a handful of the most common or most useful ways. Vi IMproved -- Vim combines both methods with good results.
The first section of the book is entitled Basic Editing; this section introduces the reader to starting and using Vim effectively without getting too bogged down in the gory details of Vim's vi heritage. In the chapter on moving around, the author begins with two methods of movement. In the details portion, the author has the reader performing more complex movements. This is a good approach, much like learning how to walk before learning how to hop, skip, jump, and dance through your document. Unfortunately this approach makes using this book as a reference very difficult. I would read sections that I wanted to use later, only to realize I couldn't find the section again. Vi IMproved -- Vim more than makes up for this shortcoming with a generous appendix detailing the Normal Mode, Command Mode, and Visual Mode commands along with a well-designed quick-reference section.
Made to Order
One of the strengths of Vim over other vi clones is Vim's ability to be used as a regular GUI application, and not just as an xterm-enhanced application.
Vi -- IMproved Vim shows not only how to use the GUI, but also how to customize the GUI to fit the reader's preferences. A good portion of this book deals with customizing Vim to suit the reader's style through the various parameters, menus, and GUI elements. Users who like their editors as stock as possible will find themselves skipping a lot of pages in this book. However even they will be tempted to try out some of the neat functions that pop up as they flip through the pages. The author conveys a sense of exploration, inviting users to experiment and try out new things with Vim.
Errata
Unfortunately, with vi and its clones, a single letter can mean the difference between moving through the document and deleting half of it by accident. Vi IMproved -- Vim is plagued with typos and errors, making this a difficult book for newbies to get into without having the errata sheet from http://vim.sf.net handy. It's understandable why a book like this would have some errors, especially with vi and Vim's terse keyboard commands.
Conclusion
Users of Vim will no doubt be thrilled with Vi IMproved -- Vim. Having a reference outside of the help menus in the program is a godsend for any user of Vim. Unfortunately the errors in this book mar what could have been the definitive book for Vim users, but for those who are starting out with Vim, or who would like to know more about Vim, this book is the perfect starting point and reference. The book covers the 5.x series of editors, but that shouldn't be a problem for most people looking to get started with the 6.x series.
If you're using Vim, you need Vi IMproved -- Vim.
You can purchase Vi IMproved from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
[mandatory flaming response about how Vi/Vim 0wnz EMACS here] :)
--pi
The errata sheet can actually be found here. The link in the story was only Vim's home page.
Rich
Mods, please check the link before
moderating to 5 Informative.
Expert Java EE Consulting
Install VIM for Solaris.
;-)
It's easy enough for a VI proofed user
Download here for example
Link is for Solaris 2.8. But you'll find the same stuff for other Solaris version an www.sunfreeware.comtoo.
(btw. emacs is here
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel
I think most people will find all the VI they need to know on the Vi reference card at vh224401.truman.edu
I prefer nVi to anything else, because size do matter. Oh, and the license is nice, unlike EMACS and Vim.
Vim does indeed rock. If you're a coder and like vim, check out
vim.sourceforge.net
Tons of plugins/tips....vi is not just for sysadmins anymore.
This is the worst book. I was a VIM newbie coming from Windowz land and the book did more to hurt me than help. It is very poorly written and has so many errors that you can't trust it. Even if the errors were fixed in a second version it'd still suck. The organization of the book is just afwul, I'd hate to see code the author generates if this spagattii is what he writes. Ick. Save your cash. Look at the customer reviews at Amazon.Com, there are quite a few "excellent" reviews, but more telling are the rare awful reviews:
... perhaps I can get a refund? Any other suggestions?
.* unless you anticipate that there would be more than one comma on a line, in which case, any command would fail. :substitute command. Take a breath Mr. Oualline, and teach the basics first.
:-) 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.
*____ Disorgainzed, Haphazard explanations -- refund time, April 8, 2002
Reviewer: Cameron from Washinton, DC
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
*____ Too confusing and too many errors, May 19, 2001
Reviewer: James Snyder from Mt. Holly, NJ United States
So far I have only read up to page 118. The large number of errors I have found so far is mind-numbing. I pity the poor beginner who has to plow through these mistakes in order to try to understand the vim program. For those who already have a copy, I ask you to compare figures 2.4 and 2.5 and tell me what is the difference between the two sets of arrows. Look at figure 2.13 and find the two outright errors, the inconsistency, and the point that might be confusing to a beginner. Read the section entitled 'How to Change Last, First to First, Last' on pages 103 and 104 and find the following:
1. The \(, \), \1, and \2 used here will not be introduced until page 213.
2. The regular expression in figure 9.2 is labeled a 'command', while the command itself is found nowhere.
3. The dollar sign in the regular expression is redundant.
4. The [^,]* could be replaced with the simpler
5. The space after the comma in the names file is not properly accounted for.
6. Who changes last, first to first, last anyway? It should be changed to first last, with no comma.
This nonsense appears just after the author has introduced the
These are not isolated problems, the whole book is like this.
My opinion is that:
1. Mr. Oualline has too much experience with vim to remember the needs of a beginner.
2. The artist who created the figures seems to have no experience with vim whatever.
3. The review process at New Riders is too careless.
***__ Does anyone actually read the books they review???, July 23, 2001
Reviewer: David F DelGreco (see more about me) from Fremont, CA USA
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 ", 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 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.
I am a programmer who used this book to learn vim.
Before, I had been an (x)emacs user for several years, but I can edit far faster with vim. Not sure why the reviewer feels there were many typos in the book--I didn't notice them at all.
Every now and then, I pull down the book, open up to a random page, and learn whatever command is there. It's been a great strategy so far.
At work, having to deal with code without a decent editing environment (like SQLServer stored procedures editing) I missed vi but solved the problem with a free tool: winvi.
http://www.winvi.de
Just do :set compatible
and you get all the masochistic vi feeling you need.
Moritz
Of all the things geeks fight about, it's always the text editor that draws the most blood. For an outsider it must sound rather petty. ;)
I've found vim to have extensive documentation, though sometimes, just finding the right information is incredibly difficult to do. (I just end up grep -r ing the documentation dirs)
If you're starting out, a cheaper hard copy alternative just to get you started (since one of the major roadblocks is the initial learning curve) is the vi quick reference from O'Reilly. Nice too that it points out vanilla commands vs implementation specific ones. Information is nicely arranged too. I think I've even seen printable posters with beautifully arranged command maps.
Myself, I only use the basic commands anyways, I don't need the full set of features. I work on so many systems that customization is not an option. And sometimes, all these extra options just get in the way. Magic indents are interesting, ability to execute perl is interesting, but I don't really need them, infact I find them annoying. (I end up undoing the formating that vim magically formats for me) For my personnal system, I usually end up remove all the xyzzy and stick with the basics.
Another wonderfully useful feature of VIM is that you can record useful, exacting macros with VIM, which you certainly can't do with MSVC or, in my relatively limited experiece, any other editor other than emacs. All the power of VIM's normal mode is present in its macro capability.
Another bonus of VIM is that it can simultaneously display many different files split horizontally or vertically. While MSVC will allow you to do this, the title bars and scroll bars in all of those windows eat up so much screen space that it's not worth doing for more than two files.
Also, the syntax highlighting in VIM is better, or at least more configurable. For example, I've been using doxygen lately. I really like the different elements of a doxygen comment to show up in different colors so that I can pick out easily when I've made a stupid mistake. For VIM, I just went to vim.sf.net, found the friendly doxygen.vim syntax highlighting fixeruper that someone had written and I was in business. With MSVC you could probably write some extension to highlight the syntax the way you wanted, but what a pain.
In the end it comes down to using a tool that is designed for the task. VIM was designed for editing code. The MSVC editor employs the same basic editing philosophy as notepad or MS Word, which were certainly never designed for coding. Just a simple example: VIM has a set of commands which work in a line oriented way. Software is written in lines. Honestly, a good deal of what I find myself doing with code is moving a line or a group of lines around.
Before I starting using VIM, I was the most efficient person I knew at editing code in MSVC because I had the keyboard commands down. Now that I use VIM, I really do edit code way faster, especially for any sort of repetitive task.
There is nothing about Vim that anyone here uses that isn't part of vi.
My favorites:
This is why I like vim, but I also like emacs. People say I'm a little weird.