Linux.com

Feature

First look at Vim 7

By Joe 'Zonker' Brockmeier on May 02, 2006 (8:00:00 AM)

Share    Print    Comments   

The final release of Vim 7 is just around the corner, and it brings a number of new features to the venerable editor, including spell checking, omni completion for several programming and markup languages, tab pages, undo branches, and several other features that are worth upgrading for.

To test Vim, I compiled the 7.0f beta release on Ubuntu Breezy and used it for my day-to-day work for several days. I had been using Vim 6.3, so moving to Vim 7.0 wasn't too drastic. I was relieved to find that I didn't run into any show-stopper bugs or instability while I was working with Vim. It hasn't eaten any files, and none of the new features exhibit major bugs.

Let's take a look at what's new in 7.0.

Spellcheck

Despite the fact that I think spellcheckers are overrated, they come in handy from time to time for spotting typos and errors that you might not catch by eyeballing a file. Spellchecking doesn't prevent people from using "it's" when they mean "its," but having a spellchecker does help catch some potentially embarrassing errors.

Plugins that enable spellcheck for Vim have been available for some time, but this is the first release with on-the-fly spellcheck available as part of Vim itself. As you type, Vim will highlight any word that's misspelled after the word is completed. Vim also highlights words at the beginning of a sentence if they're not capitalized. If you're using GVim, the GUI version of the software, you'll see a red squiggly line under misspelled words rather than solid highlighting.

Vim's spellcheck feature also identifies rare words and words that may be spelled correctly, but which are out of sync with your region. For example, Vim alerts me to the use of colour rather than color, and optimise rather than optimize. Vim also detects some double words, which is a nice touch.

I found the keybindings for spellcheck relatively easy to remember. When spellchecking is turned on, ]s will move to the next misspelled word, and [s will move to the previous one. To add a word to the dictionary, use zg, and use z= to see suggestions. zug will undo an addition to the dictionary, in case you accidentally approve a misspelled word.

Unfortunately, the spellchecking feature and syntax highlighting didn't seem to like one another in Vim, though they seemed to work just fine in GVim. When working with HTML files and syntax highlighting turned on, the spellchecking feature didn't work properly at all. If I turned syntax highlighting off, though, everything was fine. It's not that difficult to turn syntax highlighting off before enabling spellchecking, but it'd be nice if both features worked at the same time.

Undo branches

If you've used Vim for any time, you're probably already familiar with Vim's undo feature -- and the ability to undo (and redo) a large number of operations to a file. Vim's undo feature has always been useful, and now Vim 7.0's undo branches feature is interesting, if not necessarily perfect. Undo branches allow you to return to the file's state by the number of changes or time interval. For example, if you've been editing a file for a few hours and decide that your draft two hours ago was markedly better, you can revert to the earlier state by using :earlier 2h. This will return you to the text state about two hours ago -- with all the changes made in that two hour span removed. If you change your mind, you can reinstate those changes using :later 2h.

While this change is somewhat interesting, it's not as fine-grained as I had hoped, and the :undolist command that shows the "leafs" in the change tree doesn't really provide a great deal of information to work from. It shows the number of changes, and the time, but no text from the changes.

However, the undo branches feature does provide finer-grained control than the normal undo and redo features found in Vim. Instead of using u (undo) and Ctrl-r (redo), you might experiment with g- and g+ to move through the text state the next time you need to undo or redo a change to the file you're working on.

Tabs

Though Vim might be a bit behind the pack on implementing a tabbed interface, it's nice to see this feature making a debut in Vim 7. Vim offers a lot of ways to edit multiple files simultaneously, but I'm used to the tab metaphor, and I'm sure a lot of other users are as well.

In GVim, tabs work pretty much as they do with any other GUI-based text editor. Tabs are placed at the top of the GVim GUI, right above the text area and below the menu and toolbar. You can cycle between tabs using the mouse or command keybinding (gt), and open or close tabs using a right-click, if the tab bar is already open.

With Vim's tab implementation, you can use the :tabdo directive to execute a command -- say, a search and replace -- through all open tabs. So, for example, you could run :tabdo %s/oldvariable/newvariable/g to change the name of a variable through two or more files almost as easily as doing the search and replace on a single file.

The only thing I'm not crazy about with Vim's tab implementation is that I have to learn a new set of keybindings for creating, closing, and cycling through tabs -- or spend the time modifying them. Firefox uses Ctrl-t for a new tab, while the default for Konsole is Alt-Ctrl-n, Bluefish uses Ctrl-n, and so forth, while Vim only offers :tabnew by default. Ctrl-t is already used for jumping to an older entry in the tag stack.

Despite that minor annoyance, I'm glad to see tabs in Vim. Tabs suit my writing and editing style much more than working in split viewports or using Konsole tabs to deal with multiple files.

Code completion and more

The new version of Vim offers a new code completion feature called omni completion that many programmers are likely to find useful. If you're editing, for example, a page in HTML, the omni completion feature will offer possible tags if you press Ctrl-x Ctrl-o. If Vim finds matches, it will pop up a menu that offers all of the possible choices. I tried this a bit with HTML, and the release notes say that C, JavaScript, Python, Ruby, and XML are supported as well.

One small but significant feature in Vim 7 is the addition of a :sort command. Let's say you have a list in Vim that you'd like to sort alphabetically. Simply specify the range and by default Vim will sort the lines by the first character in the line.

Vim now has its own internal grep feature, :vimgrep. This is probably more interesting for Vim users on platforms without grep, but it's useful for Linux and other *nix users as well. :vimgrep lets you search through files (including gzipped and remote files) for a search string, and then load the matching files for editing.

This release also adds the :viusage and :exusage commands, which display a full list of normal and ex mode commands that can be used with Vim. It's a very terse reference, but it's comprehensive and useful to have.

I haven't had the opportunity to test out Vim 7.0's addition of printing support for multi-byte characters, and extended Unicode support.

Upgrade today

I've been using the Vim 7 exclusively since the release of Vim 7.0f beta last month. So far, I've only noticed one minor glitch -- the spellcheck/syntax issue -- and that's a small price to pay for on-the-fly spellchecking, tabs, sorting, and all the other goodies available.

If you're already a Vim user, grab the new release as soon as possible. If you haven't tried Vim before, now's a great time to start. If you're interested in trying out Vim 7, the source code is available from the development page on Vim.org.

Share    Print    Comments   

Comments

on First look at Vim 7

Note: Comments are owned by the poster. We are not responsible for their content.

Vim 7

Posted by: Anonymous Coward on May 03, 2006 04:33 AM
Looks like we need to wait for Vim 8 for the emacs emulation mode.

#

You do know that...

Posted by: Anonymous Coward on May 03, 2006 07:40 AM
... in vim you can bind any feature you want to any key you want, right? You could assign C-t to<nobr> <wbr></nobr>:tabnew and whatever else to searching the tag stack.

#

Re:You do know that...

Posted by: Anonymous Coward on June 10, 2006 10:10 PM
Here's how to remap quickly:
map <C-t> <ESC>:tabnew<cr>

it destroys the normal c-t but you get the idea and could choose what you wnat

#

Re:"vimgrep"?

Posted by: Anonymous Coward on May 03, 2006 09:20 AM
The "slash search" (/) and "upward search" (?) in vi only search the current file.

I haven't tried the new vimgrep, but apparently it allows you to search a specified set of files in a given directory (e.g., "*.h", or "*.ini", or "April*" or whatever).

It's just a convenient alternative to opening an xterm and cd'ing to a directory and executing a grep command.

#

Re:"vimgrep"?

Posted by: Anonymous Coward on May 03, 2006 09:47 PM
Plus you can use ":cwin" to get a list of all matches. You can then select one of the matches and vim jumps right to it (even opening the file if necessary)!<nobr> <wbr></nobr>;)

#

Too much bloat.

Posted by: Anonymous Coward on May 03, 2006 03:34 PM
Vim *is* useful for quick edits. Otherwise its commands are difficult to use compared to a full-fledged editor (like emacs).

So what's the point of adding yet more features to it? Emacs is much more mature (and programmable).

I think people are adding features left and right without thinking, a common practice when you have too much time free.

I don't mind---just make sure vim-minimal is still available. The rest is bloat....

#

Re:Too much bloat.

Posted by: Anonymous Coward on May 03, 2006 07:23 PM
thats a silly thing to say. vim has plenty of
functionality to rival emacs.

#

Re:Too much bloat.

Posted by: Anonymous Coward on May 03, 2006 08:28 PM
dude, that was such a troll. emacs is the most bloated thing to have ever existed.
lots of people use vim for everything and it works great; you can't possibly think that the emacs keybindings are more intuitive??? it sounds like you use xemacs and use the menus, and therefore think it's better; use gvim if you're one of those...

the truth is: people start with vim or emacs, and learn the keybindings. both are so weird, intricate, and take so much time to learn in depth that once you've learnt one, you don't want to switch. both are excellent. i started with vim because it's everywhere and i know it's always there. i see how emacs is nice, but i just wouldn't want to learn a whole new set of keys when i'm used to vim...

#

Re:Too much bloat.

Posted by: Anonymous Coward on May 03, 2006 08:29 PM
A practiced vi user can be a little bit faster than a practiced emacs user simply due to less hand-travel.

Add the fact that vi users don't carry around a gigantic<nobr> <wbr></nobr>.emacsrc file means that vi users don't have to copy anything or set anything up- they're just there and ready to go.

Finally, because vi starts so much more quickly than emacs means that they can spend their time using UNIX instead of using EMACS for the other tasks that need to be done.

VIM is a series of logical improvements to vi- and for the most part, vi users are quite happy with VIM, and enjoy being able to take advantage of the things emacs offers emacs-users without having to sacrafice their productivity.

#

Re:Too much bloat.

Posted by: Anonymous Coward on May 03, 2006 09:06 PM
Finally, because vi starts so much more quickly than emacs means that they can spend their time using UNIX instead of using EMACS for the other tasks that need to be done.

Yes, vi starts quicker and is much more convenient than emacs for editing single files. But the slow startup isn't so bad that it would steal you that much time. And usually, emacs users won't start it for every file from a console. They have dired, buffers and eshell. It's a different working philosophy. I'm still tempted to switch over to vi because of the awkward key sequences (might try out viper-mode first<nobr> <wbr></nobr>;-)), but I think emacs provides better hacking/tweaking experience.
I guess both need a lot of time to learn, but I think both are worth it.

#

Re:Too much bloat.

Posted by: Anonymous Coward on May 03, 2006 09:50 PM
Stop trolling... why start a new vi vs emacs war?

If you don't like it, don't use it.

For me, vim has improved my editing speed, so I'll stick to it no matter what!<nobr> <wbr></nobr>:)

#

"Too much bloat"?

Posted by: Anonymous Coward on May 04, 2006 12:22 AM
just make sure vim-minimal is still available. The rest is bloat....

You can say you prefer emacs more than vi/vim, that's fine. But don't argue on the grounds of bloatedness. Emacs is one of the oldest and best examples of bloat anywhere in the software world. Evening suggesting that vim is bloated (when compared to emacs) indicates either a) you are a blind emacs zealot, or b), you're an idiot.

#

Too much bloat?

Posted by: Anonymous Coward on May 03, 2006 08:46 PM

What a troll.



Vim *is* useful for quick edits. Otherwise its commands are difficult to use compared to a full-fledged editor (like emacs).



I don't mind---just make sure vim-minimal is still available. The rest is bloat....



So which is it... is EMACS (bigger than Vim) full-fledged while Vim (smaller than EMACS) is bloat? Come on.



So what's the point of adding yet more features to it? Emacs is much more mature (and programmable).



You obviously don't know anything about Vim. Not only has vi been around since the dark ages, Vim has what's called Vimscript... which makes basically anything possible... from e-mail clients to directory listing to custom compiles... hell, Vim will include the Python interpreter if you want it to.



Of course, those are "features", so if that's bloat, then quit complaining.

#

Re:Too much bloat?

Posted by: Anonymous Coward on May 03, 2006 09:53 PM
So which is it... is EMACS (bigger than Vim) full-fledged while Vim (smaller than EMACS) is bloat? Come on.

They both have their uses:

- Vi(m) for quick edits on the console or terminal window.
- emacs for longer edits (e.g., writing a paper).

I've used been using vi for 16 years. The 2-mode input was good for all kinds of terminals that might not have meta keys, but difficult to use today (and unnecesary).

You obviously don't know anything about Vim. Not only has vi been around since the dark ages, Vim has what's called Vimscript... which makes basically anything possible... from e-mail clients to directory listing to custom compiles... hell, Vim will include the Python interpreter if you want it to.

I suspected it does. What I'm saying is that it's unnecessary for its intended use.

#

Re:Too much bloat?

Posted by: Anonymous Coward on May 03, 2006 10:13 PM
Quick edits? LOL I use it for every text edition I need!

"Its intended use"? Don't you mean "My intended use of it"?

trolllllllll<nobr> <wbr></nobr>:P

#

Re:Too much bloat?

Posted by: Anonymous Coward on May 09, 2006 07:15 AM
The 2-mode input was good for all kinds of terminals that might not have meta keys, but difficult to use today (and unnecessary)<nobr> <wbr></nobr>..(SNIP).. What I'm saying is that it's unnecessary for its intended use.



That might be how you use it. Personally I hate emacs. I like a moded editor. Someone once said to me the only real difference between vim and emacs is do you like modes or not. If you do, use vim. If you don't, use emacs. I work faster in vim.

#

syntax and omni-completion

Posted by: Anonymous Coward on May 04, 2006 06:16 AM
Syntax and omni-completion are working together very good but syntax files
needs spelling specific corrections. Author of article probably has somewhere
private copy of HTML syntax file which overshadowed default one and overwritten
those corrections:<nobr> <wbr></nobr>:help spell-syntax

#

sorting is just quicker on Vim 7

Posted by: Anonymous Coward on May 04, 2006 08:43 PM
It was/is possible to sort text in Vim. Just "set equalprg=sort", do a visible select, press "=". Done!<nobr> <wbr></nobr>:)

There are plenty other ways to do it. This one I've been using for ages. Good to see a<nobr> <wbr></nobr>:sort command, anyway. Quicker<nobr> <wbr></nobr>:)

#

Re:sorting is just quicker on Vim 7

Posted by: Anonymous Coward on May 09, 2006 07:27 AM
Only if `sort' is installed. In that case, you could also do that visible select and then type<nobr> <wbr></nobr>:!sort (and you can pass arguments to sort like -k 2 or -k 7, and many more). If you are planning to sort many files, maybe your idea is better. Otherwise, I preffer to use = for indenting the text.

---

Will we ever have vim inside text boxes?
Ctrl-C<nobr> <wbr></nobr>:x

#

Re:sorting is just quicker on Vim 7

Posted by: Anonymous Coward on May 17, 2006 01:25 AM
Will we ever have vim inside text boxes?

Yep. <a href="http://mozex.mozdev.org/" title="mozdev.org">http://mozex.mozdev.org/</a mozdev.org>

#

"vimgrep"?

Posted by: Administrator on May 03, 2006 08:48 AM
What does it do that the slash command doesn't?

#

Good broad overview.

Posted by: Administrator on May 03, 2006 11:14 PM
I tried out vim 7 myself a few weeks ago on both windows and mac (just the gui version).

In regards to the tab feature I'd like to point out that it is more powerful than this article suggests - each tab preserves all window splits within the tabs. This is especially useful, and more featureful than simply switching buffer windows. Hypothetically this means you could use vimdiff on file a.txt in one tab, and then have another tab where you just edit a.txt plain jane. Hypothically - it almost works like that (the plain jane one sadly switches into diff mode as well). Another point wrt to tabbing missed in this article is that it works both in vim and gvim.

Other nice features that I'm pretty excited about:

The file browser feature (netrw) is much enhanced.

You can now do row and column hilighting (ala eclipse (well, eclipse doesn't have column hilighting). This is, in my humble opinion a long awaited for feature (small though it may be).

The builtin vimscript language is growing up: it has dictionary, list, and function-reference language enhancements. Btw - did you know there is a unit testing framework for vim - check it out (vimUnit). Very handy.

There are a few more user scripts that are now included with the default vim distribution. The most notable in my book (I've been using it in vim6 for a while, but it's nice to see it going main stream) is the 'GetLatestVimScripts', which automatically upgrades your vimscripts to the latest version, if the vim script is in the www.vim.org user script repository. Very handy.

------------

You flamebaiting emacs users up there need to get over yourselves. Vim is not vi. It is a 'full fledged editor' that is 'programmable'(vimscript,perl,python,ruby, and now scheme), as you say. Even with all its bloat (which is okay, it isn't vi after all), it still loads up faster than emacs.<nobr> <wbr></nobr>:P

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya