Vim 6.4 Released

file cabinet writes to tell us that for the first time in more than a year Vim has released a new version. Version 6.4 stable was released yesterday and while there are no new features added they are touting dozens of bug fixes.

Comments

Why are we hiding from the police, daddy?

[(1 -sqrt(5))*(2**-1)]

"Because we use vi , son; they use emacs."

In good sadness, though, I'm looking forward to the spell-checking in Vim 7.

Re:Why are we hiding from the police, daddy?

[LnxAddct]

The vimspell script works well.
Regards,
Steve

Re:Why are we hiding from the police, daddy?

[falzer]

VIM is *not* user friendly, and until it is VIM will stay with <= 1% marketshare.

Take editing text. Vim zealots are now saying "oh editing text is so easy, just use the hjkl keys to move around and use ":%s/apple/apricot/gi" to do a search and replace. Yes, because typing in "5kck}" is so much more intuitive than simply moving the cursor, selecting two lines of text with the mouse, then hitting the } key.

VIM zealots are far too forgiving when judging the difficultly of VIM interface issues and far too harsh when judging the difficulty of Notepad issues. Example comments:

User: "How do I fucking edit this goddamn text file!? Why does Linux only come with vi installed?"
Zealot: "Oh that's easy! Just go vim <the file you want to edit>. No no, wait, don't type anything yet. It won't work the sa-- ok hit escape, ok, hit u a few times, ok you're back to where you started. Now vi works a little differently than most text editors: there is command mode and edit mode. Vim starts in command mode where you issue commands (such as hjkl) to move the cursor around, d followed by a movement command to delete lines of text, or i (for example) to insert text. Pretty much almost every letter of the alphabet (upper and lower case) is a command. When you go into a text editing mode by issuing the appropriate command, you type your text like normal then hit escape to back out. You type :q to quit, or ZZ / :wq to save and quit. Sometimes you need to put in a ! after a : command to force it. Quite elegant, don't you think?"

User: "How do I edit text files using notepad?"
Zealot: "Oh God, you have to use the graphical luser interface to open a text file. Then use the arrow keys (or optionally mouse) to position the cursor where you want to type. Now you've gotta actually enter in the text using the keyboard! Careful though, it might break, it just blithely assumes that what you're typing is text and not commands!"

So, I guess the point I'm trying to make is that what seems easy and natural to VIM geeks is definitely not what regular people consider easy and natural. Hence, the preference towards notepad.

Re:Why are we hiding from the police, daddy?

[Demerol]

No one says vim is user friendly. It's not supposed to be. It's supposed to be powerful, and it is. It's hard to learn and it probably always will stay with 1% of the market share but I don't think the developers really care for increasing market share. Remember...it's free in every sense.

And in reply to the troll before you:

vim does have mouse support (:set mouse=a) in both terminal and, obviously, gui modes.

Also, :set wrap will solve your other qualm.

Re:Why are we hiding from the police, daddy?

[Moloch666]

Hm, for some reason notepad doesn't work from ssh. With commands like cl, cw and so on. VIM makes the perfect editor for quick edits on a remote computer.

Re:Why are we hiding from the police, daddy?

[Alan]

Nothing is wrong with those, however generally speaking, they aren't installed by default on a unix box, while vi/vim/elvis or some other vi-type editor is installed on pretty much 100% of every unix box I've been on, from linux to solaris to *bsd to hpux. Personally I love vi, however I understand it's not for everyone.

Everyone who works with unix should learn how to use vi though, for the simple reason that it's on pretty much every unix box out there, and is the editor you're pretty much guarenteed to be able to have available if $random_person asks you to quick jump on their $unix_box to [do something].

Re:Why are we hiding from the police, daddy?

[hereticmessiah]

Have you read Neal Stevenson's "In the Beginning Was the Command Line"? If you had, you wouldn't be spouting this nonsense.

Seriously, go read this section: http://tinyurl.com/9qukb

In it, he compares two devices: a heavy duty industrial drill called the Hole Hawg, and your basic power drill. Both do the same thing--drill holes--but their intent is different. The Hole Hawg is designed to drill through anything, whereas the regular power drill is designed for household use. The power drill lacks the power of the Hole Hawg, but has safety features that the Hole Hawg can't afford to have because of this. Whereas the Hole Hawg will keep spinning if it hits something hard (and therefore requires a large amount of strength to keep steady), whereas the power drill will slow down if it encounters too much resistance.

Similarly, Vim is the Hole Hawg of text editors, whereas notepad is a regular powerdrill. Both have different intentions, with the former being designed for heavy-duty text editing as a programmer or highly technical user would need, and the latter designed for occasional light editing, the kind most non-technical users do. The intent is different and so the interfaces differ.

It's very, very difficult to create a deep, powerful interface that is easily discoverable. At best, you can make it as learnable as possible. This is what Vim attempts to do. Notepad goes for a shallow, easily discoverable interface at the expense of power.

Re:Why are we hiding from the police, daddy?

[Vintermann]

I disagree that everyone should learn to use vi. It's not a cost-effective investement in my opinion (nor is emacs, although there are some modes that might have changed my mind if I was heavily into the things they deal with). You spend months typing like a turtle. By the time you actually get up to a reasonable speed, you have used so many seconds, minutes and hours that you'd need some truly impressive productivity gains to make it worth it.

The folks at Xerox PARC actually experimented with this. They found out that the basic, mouse-based text editor saved very much in training costs, while actually being as fast as or faster than the traditional editors.

If some random person asks me to edit a text file on his unix box, I install some tiny text editor for him (the editor in midnight commander works fine for me). If he won't/can't let me, or the unix version is so uttely weird that I can't figure out how to install it, I say "let's sign a support contract, then we can talk about it".

That said, for you who have already invested a couple of months of your lives learning the arcana of vi (and on this thread, I suspect there might be some ;-), it's not really worth it to switch to a post-PARC editor. Not if you're already up to speed. While skills in regular modern text editors are useful because they are transferable, they are quick to learn anyway, that's what's nice about them.

Re:Why are we hiding from the police, daddy?

[Afrosheen]

The thing wrong with pico is it isn't free, hence why distros like Centos and Whitebox include its free clone, nano. http://www.asty.org/articles/20010702pine.html has a decent article detailing pine's default text editor, pico's licensing scheme and why it's bad, and goes on to explain why nano is a suitable replacement.

Re:Why are we hiding from the police, daddy?

[p2sam]

I'd disagree with you about the user friendlyness of vim. I think Vim is one of the most user friendly editors out there. It's highly ergonomic, and easy to use. BUT!! It is not easy to learn.

That's right. Easy to use, and Easy to learn are two different things. Easy to use means that one can accomplish a task with minimal effort. Easy to learn means just that, easy to learn. The two are not necessary mutually exclusive, but I have yet to see a text editor that has both.

Modern UI designers have fallen into the tar pit of designing ONLY for new users, so that tasks can be performed easily by new users, but becomes difficult to use for the power user. In that sense, most modern IDE's are easy to learn, but hard to use.

In my opinion, I'd rather spend a few days learning to use a tool that will increase my long term productivity.

Re:Why are we hiding from the police, daddy?

[p2sam]

For a programmer, who spends 7.5 hours a work day using a text editor, it's probably worth it to use the most effective editor, even if it takes a couple of months to get to speed on the tool. (Note: most people learn enough vi to get by in a couple of days.)

Re:Why are we hiding from the police, daddy?

[ChrisGilliard]

Hey, at least vi is better than ed. If you haven't tried it, type 'ed at your terminal and you'll see what I mean.

Re:Why are we hiding from the police, daddy?

[trewornan]

It's highly ergonomic, and easy to use

I tend to use vi more than other editors but the one thing that really bugs me is having to move my hands to reach the Esc key all the time. Does anybody here know of an alternative? Some combination with Alt or Ctrl maybe?

Re:Why are we hiding from the police, daddy?

[akaempf]

Ctrl [ acts as escape. Vim also lets you reprogram other key combinations to act as escape, e.g., Ctrl Space.

Re:Why are we hiding from the police, daddy?

[HerrGoober]

Three words: Carpal Tunnel Syndrome

The less you have to use the mouse the more opportunity you have for better posture at the desk all round.

Re:Why are we hiding from the police, daddy?

[Fledsbo]

Remap the (totally useless) CapsLock key to escape. Voila!

Re:Why are we hiding from the police, daddy?

[Fred_A]

I've been using vi editors fo ages for the simple reason that nothing else was available. Well, I wouldn't have used Notepad (I don't think I've ever used notepad) but something with a more modern interface would certainly have been welcome. And if you don't like vi, go play with the system editor on VMS, it's not much better.

The purpose of vim isn't to make a user friendly editor, it's to make a better vi. vi isn't a user friendly editor, it's a horrible relic from another age which however happens to be :
1. Quite powerful
2. available on pretty much any Unix machine
3. therefore well known by most Unix users

When I came upon machines that could run Emacs I usually ran that because I found that it was more comfortable for me, however I just used what was available, so learning vi and Emacs was just what everybody did. You were free to prefer whichever.

However the main advantage of vi over Emacs is that vi (the original) is much more lightweight and can typically be used when the system is slightly broken (having a statically linked vi is always a good idea). I'm not sure that's still true with vim.

I still tend to point out vi to beginning Unix users (the tinkering kind, not the office desktop users) mentioning that for historical reasons (many things on Unix are there for historical reasons), vi is the default editor on most systems and you can usually rely on it being present. So learning a subset of commands (insert, delete, replace, save, quit without saving) is always a good idea.

On a side note, when I installed Gentoo on the machine I'm typing this on, the installation manual said I had to edit a few files. Except there were no editors installed. Or at least no vi. No vim either. No vi*.

It took me a good 15 minutes to figure out that a thing called "nano" (of which I had never heard) was installed by default to be used as an editor while vi was optional. This is a typical braindead decision. Adding a user friendly editor is always good, removing the widely acceptly default editor (quirky as it is) is always bad.

Re:Why are we hiding from the police, daddy?

[Peter La Casse]

Actually, in about one month you should be able to gain reasonable speed.

My experience was even faster than that. The number of basic commands I needed to learn was very small, and after using vi-like programs for years now, I still have barely scratched the surface. I never did quite get the hang of using hjkl for movement, but that is seldom an issue these days. I'm currently working on using the native cut and paste commands instead of the mouse and menu.

Way back when, vi was the only text editor on a class of systems I needed to work on, and I figured that if I used it for everything I wouldn't need to constantly change my mode of thinking when switching from system to system. I was pleasantly surprised to learn that gvim for windows combined vi semantics with all of the windows editor semantics that I was used to. (My previous text editor was PFE.)

Re:Why are we hiding from the police, daddy?

[Fred_A]

That's what your nose is for.

Re:Why are we hiding from the police, daddy?

[J'raxis]

Polish apparently uses jj to transliterate Arabic; see Omar Chajjam. I don't know Polish, but it probably uses it for other things, too, since transliteration generally means bringing foreign words into your language's orthography.

That also ignores the fact that people don't just use editors for typing natural text but for typing code: I'm sure someone's source code contains name tokens with jj in them.

Re:Why are we hiding from the police, daddy?

[QuestorTapes]

> ...Vim is the Hole Hawg of text editors, whereas notepad is a
> regular powerdrill. Both have different intentions, with the
> former being designed for heavy-duty text editing as a programmer
> or highly technical user would need, and the latter designed for
> occasional light editing, the kind most non-technical users do.
> The intent is different and so the interfaces differ.

Exactly correct. That's why a lot of people preferred WordStar to Word or WordPerfect. and we still remember the hotkeys for thos editors that do emulation (Borland's Turbo C++ editor, VB classic, tons of programmer's tools )

> It's very, very difficult to create a deep, powerful interface
> that is easily discoverable.

True.

> At best, you can make it as learnable as possible.

Have to disagree; in addition to making it as learnable as possible, you need to make it, as you said, "discoverable". Discoverability is aided not by a shallow interface, but by making experimentation safe. It should be very easy to:

- see underlying patterns in the UI, to consider what -might- be done
- easily distinguish actions which did something from those which do nothing
- undo anything, thus encouraging the user to try new things.
- as modeless as possible, so that actions which do nothing -most- of the
    time do nothing destructive the other times

This is one area where vi is not as good as some tools. Note that this is not an area where most tools are good, and vi is poor. This is an area where most tools are poor, and vi fails to rise significantly above the majority.

> This is what Vim attempts to do. Notepad goes for a shallow, easily
> discoverable interface at the expense of power.

Yes; other tools attempt to increase both power and discoverability, with mixed success.

Re:Why are we hiding from the police, daddy?

[FuzzyBad-Mofo]

Sir, I must take exception to your post. Notepad is in no way, shape, or form a regular powerdrill! It's more like one of those toy hand cranked drills that excels at drilling through cardboard.

Re:Why are we hiding from the police, daddy?

[blair1q]

The conclusion most will draw from your argument rests on a faulty implication: that vi was intended to be more featureful than Notepad.

If Bill Joy had had access to the screen capabilities of a graphics engine, instead of a glass-TTY, there might never have been a Notepad, because vi would have had a mouse and a cursor and still would have had need to put all of vi's "power" into the editor he chose to write.

Vi isn't as "easy to use" as Notepad because Bill Joy lacked the technology. Notepad isn't as "powerful" as vi because Microsoft lacked the concern.

None of this stopped Richard Stallman, who put everything into emacs. But then, nothing stopped Richard Stallman, who put way too much into emacs, and suggested the problem was that you lacked two extra fingers and an eidetic memory for command strings and an understanding of the obvious need for operating-system internals in a text editor...

Re:Why are we hiding from the police, daddy?

[valintin]

I think most people in the know, have already remapped the "caps lock" to the Control key.

I swap the mapping of the ESC and `~ keys to bring the ESC key closer.

Re:Why are we hiding from the police, daddy?

[digitect]

Vim's not easy to use?

I beg to differ: Cream for Vim.

I just want to say thanks.

[CyricZ]

I want to say thanks to all of the VIM developers who have helped create such an amazing piece of software. Indeed, I don't think we can even begin to consider how much other software has been written by developers using VIM.

Re:I just want to say thanks.

[p2sam]

Vim is charity-ware, please donate.

http://iccf-holland.org/index.html

Re:I just want to say thanks.

[CodeRx]

Bram is now taking donations to help fund further Vim development. If you donate >10 euro's, you get to vote on new features. This is a great way for those of us who have written countless thousands of lines of code in Vim to show our appreciation.

Re:I just want to say thanks.

[Mr. Hankey]

Start up a copy of vim, type ":about uganda" (without quotes) and press enter to find out. In short, the author of vim did volunteer work for the clinic for a year and has visited there on several occasions since then. He wishes for others to help the clinic as well.

Bugggg fix only. nice

[poind3xt3r]

Dozens of bugs have been fixed, runtime files were added and updated. There are no new features They are focusing more on fixing problems rather than add new features and in essence adding new bugs. Its rare to see updates which are meant for donzens of fixes. A smart approach.

Might have taken a while....

[ELiTe185]

More than a year? At least that's quicker than Microsoft....

Re:A Year?

[Spit]

How many new features can you add to VI? VIM is near perfect software and has been for years. Free licence has done its work already with this software, troll.

That's not surprising.

[CyricZ]

I mean, it is the 6.4 release. Many projects typically do not add features after a major release. It's the minor point releases that focus on fixing bugs. So in this case it's the fourth round of bugfixes.

Intellisense #1 feature, pay Bram to add it

[Morganth]

I just wanted to point out that Intellisense (context-sensitive completion based on parsing or "understanding" code) is the #1 most voted VIM feature. You should add your own votes (with your hard-earned cash, if you will) if you want to see this feature come to VIM.

I personally do want this feature. It would make VIM the perfect text editor, IMO. Right now, VIM's completion is already pretty good, and a couple people have implemented completion as a plugin, but it usually ends up being a hack. I think Bram can figure out a nice way to do it for Vim 7.

People who know how to use VIM well find themselves really productive in it. But, that said, I end up being slightly more productive writing Java code in Eclipse, ONLY because of completion, even though all my other editing features from VIM aren't there (or are buried).

What I usually end up doing is keeping a console handy and switching between Eclipse and VIM when I have to do Java, but that's not that nice. I think Vim can pull this off.

http://www.vim.org/sponsor/vote_results.php

Re:Intellisense #1 feature, pay Bram to add it

[kaisyain]

He's already added it in the Vim 7 sources. It was initially called occult completion but is now called omni completion. (Intellisense is a trademarked term.) Read the vim dev list for more details.

Re:Intellisense #1 feature, pay Bram to add it

[Anthony Liguori]

People who know how to use VIM well find themselves really productive in it. But, that said, I end up being slightly more productive writing Java code in Eclipse, ONLY because of completion, even though all my other editing features from VIM aren't there (or are buried).

Sorry, I don't mean to be a bastard here, but this is my biggest pet peeve. I *hate* Intellisense or whatever the hell it's called. I think syntax autocompletion is ruining a new generation of programmers.

Here's my reasoning. Writing code that always works is hard. Writing code that works some of the time is easy. To write code that works all of the time you have to understand the exact behavior of every function you call and handle all possible scenarios properly. It's the difference between writing:

read(fd, &myInt, 4);

And then writing a wrapper around read that checks for EAGAIN, EINTR, performs endianness conversion, handles partial reads, and potentially implements this all asynchronously. Back to my original point though, it takes time to learn all of the sublities of an API. The best way to learn them is by studying the interfaces (reading manuals, man pages, whatever).

If you cannot remember the name of a function, go back to the manual and study it. You're going to not handle the edge cases of it. If it's Java, you'll ignore a potential exception. If it's C, you'll miss a potential error code.

I'm not against all the features in things like Eclipse. Some of the refactoring stuff is useful. It's just intellisense that drives me nuts.

Re:Intellisense #1 feature, pay Bram to add it

[aCapitalist]

Guess what. You don't have to use intellisense if you don't want to. That was easy wasn't it.

Re:Intellisense #1 feature, pay Bram to add it

[plastik55]

Eh? When Eclipse offers completions of a function for me it shows me the javadoc! So when I 'm getting ready to call a function I can see all the edge cases and caveats documented for me on the screen. That's much better than being a macho/masochistic programmer and thinking I remember everything about a function from the last time I used in in a different context.

No one remembers all the edge cases, especially people who think they've got it all so memorized that they don't bother to double-check the documented behavior while they're calling functions.

Re:Intellisense #1 feature, pay Bram to add it

[tehshen]

If you cannot remember the name of a function, go back to the manual and study it.

Don't think it's just for when you forget something - most of the time, I remember how to type gtk_menu_get_attach_widget(), and what arguments it needs; I just can never be bothered to type it over and over again.

Re:Intellisense #1 feature, pay Bram to add it

[Splab]

I got tab completion in my vim:
In my .vimrc:

function InsertTabWrapper()
        let col = col('.') - 1
        if !col || getline('.')[col - 1] !~ '\k'
                return "\<tab>"
        else
                return "\<c-p>"
        endif
endfunction

in .vim/ftplugin/c.vim:

set dictionary-=~/.vim/clist.txt dictionary+=~/.vim/clist.txt
set complete-=k complete+=k

this gives me auto completion in c files where .vim/clist is a list of c functions.

hats off to Bram, Bill Joy, and ATT

[yagu]

Sometimes I think Bram Moolenaar doesn't get enough credit for what he's done almost single-handedly. vim is an amazing piece of software. I've been using it almost since the day it arrived, and I was a vi user who thought vi was everything. But Bram brought vim and immediately began carefully, but boldly, extending vi, without the constraints of waiting for POSIX standards anointing any changes to vi.

Credit to Bill Joy also (and to AT&T, for "sc") for the pre-cursors and inspirations for vim.

vi in and of itself is a workhorse with its philosophy of "no gui or mouse necessary", and while vim now has its gui rendition (I never use it), the underlying philosophy and principles remain intact. Color syntax alone is worth it. If you haven't tried vim, you should. For raw and pure editing, there's nothing better (don't flame me, emacs people... please). I've often challenged people to editing faceoffs... where I'd dialup at 1200 baud (yes, I've been around for a while), and they could use ANY editor, at any connection speed, and I'd beat them at making a set of edits against a file.)

(Aside: how many vi users out there have spuriously put "www, jjj, bbb, G " in their comments when they used the browser text widgets.)

Re:hats off to Bram, Bill Joy, and ATT

[trb]

Credit to Bill Joy also (and to AT&T, for "sc") for the pre-cursors and inspirations for vim.

Joy wrote vi, with help from Mark Horton, both then at UC Berkeley. This back around 1980, on PDP-11s, and eventually Vaxen. If by se, you mean the Bell Labs PWB screen editor, that was quite a clumsy piece of software meant to compete with vi, and with the ports of emacs to UNIX (separate versions by Gosling and Zimmerman, predating the GNU effort). I am shocked that anyone remembers PWB se, it was short-lived and pretty obscure. How obscure? Is there one ref to it on the web? That's obscure!

While you're thanking, you might want to thank the UNIX folks who brought us "ed," Ken Thompson (and Kernighan wrote the docs, as always). The ed command set survives as the basis for vi/vim :command mode - including the regexes. ed was based on editors that came before it of course, especially QED.

Re:hats off to Bram, Bill Joy, and ATT

[morcego]

Ignoring CSV for a minute, if you'd like to replace all text from the 20th through 23rd characters of arbitrary text with the string "abcd", how would you do it?

You mean something like this ? :%s@^\(.\{19\}\).\{4\}@\1abcd@g

Although I would usually do that using sed, not vim.

In text processing, the workload determines the ability of a "ve" user (internal IBM tool) to surpass my vi efficiency. Typically, it's when the ve user mouse selects a column and then does replaces on it. I'd like to mimic this behavior using only my qwerty pad and some newly aquired vi skills.

Oh my god, they are still using that ? I remember the religious wars of VE versus VX when I worked there, pretty much like the VI versus EMACS wars we see out here.

The real trick is a good background in sed and regular expressions. Then you can use :%s to your heart content.

Re:hats off to Bram, Bill Joy, and ATT

[raehl]

Is there one ref to it on the web?

Way to ruin it buddy.

Bug fixes

[patrickclay]

I hope they fixed the bug that made you type all those weird key combinations to write to a file and save.

Re:Bug fixes

[Waffle Iron]

You can fix it yourself. Add to your .vimrc file:

nmap <C-S> :w<CR>
imap <C-S> <Esc>:w<CR>

Now Ctl+S works just like it does in notepad.exe.

Re:Bug fixes

[dedazo]

Or you could just source mswin.vim (typically found under $VIMRUNTIME) and essentially have a MS-style keymap emulation. Put it in your ~/.vimrc, and make sure you include the 'behave mswin' line before you source it.

Re:Yes, but is it better than emacs??

[CyricZ]

Perhaps the use VIM for the same reason you seem to enjoy using NeXTSTEP-styled systems: they just find it works for them. It allows them to be as productive as they can be.

Re:Yes, but is it better than emacs??

[Hamster Of Death]

Some people grow attached to their pointy sticks and stone hammer tools when building a sub par house.

Re:Yes, but is it better than emacs??

[rebug]

Anyway I've never understood why people feel this compulsion to use a mode-based editor when there are so many wonderful editors out there today.

Uhm, because some of us like modal editors?

I for one...

[_Hellfire_]

...welcome our new 18 fingered overlords!

(yes I'm a daily vim user)

Keep up the fantastic work guys - vim is one of those apps which is actually a pleasure to use.

That's nothing!

[earthbound kid]

The last version of Emacs came complete with Vim v. 10.03c! ;)

Not only is it a fantastic editor...

[CyricZ]

... but it is also a fantastic pager. Using it instead of less or more to quickly scan over source code is a blessing! Indeed, you get the syntax highlighting of a GUI editor, but without the overhead. You can view files instantly from the command line, and they're very nicely formatted.

Re:Not only is it a fantastic editor...

[Tumbleweed]

...it's also a tasty salad dressing! Mmm...now *that's* _Vimtastic_!

Re:Bugggg fix only. nice

[keesh]

No no no. The features are being added in the 7.x branch, which you can get from CVS. 6.x is purely for maintenance (ie bugfixes). This is a mixed blessing... It means 6.x is extremely stable, but if you want new goodies like spellchecking and intelligent autocompletion, you have to switch to the CVS only branch.

It's a tricky decision. Some projects are way over on the side of "keep throwing out new versions with new features and new bugs". Vim is way over on the other extreme: "release 'new feature' releases every few years and keep the stable branch working". For end users it's a mixed blessing.

Fortunately, the 7.x branch is pretty much stable (as in every day usable) at the moment. I've been using the Gentoo ebuilds (package.masked), which means I get a CVS snapshot which has been at least reasonably well checked and had any icky bugs fixed. I'd hate to miss out on the new toys. The 'numberwidth feature alone makes it worth the upgrade, even if 'spell didn't exist.

Did someone mention the Fantastic Four?

[Rhinobird]

Because, I thought that I distinctly heard the words "Flame On".

Like priming an enclosed area with flammable fumes. Someone is going to mention Emacs and this place is going to explode.

Wishes for the next VIM and why use Vim

[MrBoring]

First, I use VIM not so much because I think it's the best text editor, but because it's corrupted my thought process so much that I keep using those cryptic Vi commands in other programs when typing more than a few words. That said, I do feel most productive in Vim or Vi on systems which don't have Vim (such as z/OS). People don't understand why one would use Vi, until they've mastered it so well that they can nearly look at a point in the screen or think of where they want to be, and the cursor arrives there without remembering which keystrokes got them there. One of my biggest reasons for using it is that there is *no* project, workspace, solution or whatever, that I have to set up before being able to do real work. I like that.

As for wishes:
1. Better language completion, if any, language completion.
2. Better editing of binary files.
3. Support for multiple code pages. This may be possible already, but I haven't deciphered the manual enough to figure out how.
4. Support for working with change control systems. I'd like to be able to edit a file in a CCS and have the title bar reflect the release, level, etc that I'm editing, rather than a cryptic temporary file.
5. A better head on my own shoulders to remember all the set commands needed to operate it.

I really can't complain though, because if the above never got implemented, I'd still use it. I've used the editor for years, and still keep learning it.

Re:Wishes for the next VIM and why use Vim

[p2sam]

Vim has support for split screen editing for years. And vertical split screen is supported since Version 6.

How do you do a character literal?

[wk633]

Ok, some vim guru on here must know, what's the windows vim equivelent of vi's ^V? In vim, it does a frickin' paste! So how do I search for, say ^M? Or enter a macro which includes inserts I need to esc from? Not being able to find that anywhere in the help is the one thing I hate about vim.

Re:How do you do a character literal?

[Superfluid Blob]

^Q

I thought Vim was a finished project

[ravee]

I have been a ardent fan of this editor and have been using it consistently for over 3 years now. And I really feel that vim has reached a maturity level where no more development is necessary.
And if it lacks a feature, just write a plugin for the same. If you ask me this is how softwares must be developed - in a fully modular manner.

Kudos to vim developers :)

VIM?

[thomble]

...puh-lease. I write everything in machine code.

Re:Yes, but is it better than emacs??

[ocelotbob]

I use FreeBSD and never, ever look at that monstrosity known as emacs. Emacs is proof positive that RMS is a certifiably insane.

Yipee!

[callipygian-showsyst]

I am a VIM (and vi) fanatic! Which people find strange, because I'm also a Windows Zealot! I have the GUI version of VIM installed on every Windows machine I use, and I even have a version of Visual Studio that substitutes VIM as the editor.

The problem is I learned vi so long ago (back in the late 70s when Bill Joy released it), that I simply can't learn anything else. Of course, growing up on TICO and other editors before vi made moving to vi natural.

I have tried many, many times to switch to emacs and always fail. I'm just too old and too stuck in my ways to switch.

Re:Yipee!

[p2sam]

I started using Emacs in 2nd year university, but switched to Vim after realizing that I don't want to learn elisp. :) I also think I'm too old to change now, I'm 25. ;-)

Re:Yipee!

[commodoresloat]

I am a VIM (and vi) fanatic! Which people find strange, because I'm also a Windows Zealot!

I bet you're loads of fun at parties!

Re:Yipee!

[chthon]

You should be modded funny. I am 39, I have used vi(m) for almost 6 years, and now I am learning emacs. I like them both.

I find the opening of files and switching between buffers easier on emacs.

Also, when I do a compile on Emacs with 'perl -c' I can automatically go to the errors in the Perl code. In vim, I had to enter manually the regular expressions for matching those.

I do not know with what I am going to end up in the long run. vim is faster for editing config files, emacs makes it easier on long running editing sessions.

Re:Yipee!

[morbuz]

Also, when I do a compile on Emacs with 'perl -c' I can automatically go to the errors in the Perl code. In vim, I had to enter manually the regular expressions for matching those.

Vim can do that too, for almost any programming language. :compiler perl :make

Need release faster

[2Bits]

Look, as good as vim could be, at this rate, you are not going to catch up with emacs, which is already at version 21.x or something. Which just proved that emacs is much better. If you don't believe, here is some proofs:

1- Emacs has a much higher version number, which proves to be a more mature software, which proves to be better (more mature is better)

2- Even an icon such as RMS whom has been proved to be more intelligent than the average USians, uses Emacs. This shows that smart people always make the right choice, and in reverse, proves that Emacs is better than Vim.

3- Everyone in Cryptonomicon, which is the bibile of all geeks, uses Emacs. We even have a module for encryption. It would take a long time for Vim to catch up to that kind of functionalities.

4- Only in Emacs can you do Ctrl-A to move the beginning of a line. In one shot. How could you do that in
Vim? You have to Esc, then press 0, which is lame. Which just shows how advanced Emacs is in terms of maturity and functionality.

5- As the theorem goes, computer science is a science for minimizing keystrokes. Emacs, in contrast to Vim, can prove this theorem right. Emacs users press less keys than Vim users.

6- Humans have 10 fingers (some may have more, but I don't know how to grow them), and Emacs allows you to use all your fingers at one. Which shows you that Emacs has a better human user interface. In contrast, Vim users can only type one key at a time, which has no concept of fingers. That is like an interface for dogs, which can only press one key at a time with their paws.

7- Emacs allows users to stretch their fingers more, and finger exercise has been proved, again and again, scientifically, to help increase human intelligence. The more you use Emacs, the more you become intelligent. Unlike Vim users, who become dumber and dumber, and end up with paws.

8- Everyone knows that geeks do no exercise. But we Emacs users have our daily dose of finger exercise. As a result, Emacs users have better shape. Take a look at the comparison: RMS (Emacs user) vs ESR (Vi user). RMS definitely looks better, with a nicer beard too. ESR can only have a lousy Asterix moustache. And look at what these two persons said in public, which just proved points 2, 6, and 7.

9- Look at this deductive proof I'm giving right now. Only an Emacs user can attain this level of intellect.

10- As a result of the last 9 points, this proves that Emacs is better. And from an evolutionary point of view, Emacs is like modern humans, and Vim like chimpanzee.

* putting on flame suite *

Re:Need release faster

[forkazoo]

You omit one important point from your otherwise well reasoned logic...

vi users are mammals, and they flip out and kill people *all the time.* Some guy dropped a spoon and a vi user edited a whole source tree. That's what I call a Real Ultimate Editor!

Wait, maybe I'm thinking of something else. Something to do with pirates...

If you're a loyal Vim user...

[fm6]

... don't forget that it's charityware.

Maybe it is not interesting...

[Pecisk]

When I first saw vi, I thought - WTF. It is suitable for text editing!? Vi, for my point of view, is one of underdogs of software world. And yes, it really truely shines when we talk about remotently editing 40K file over 2800 baud modem or even on system with space about...emm...four megabytes? :)

Yes, there are Word, OO.o Writer, Gedit, Kedit, Pico, Nano, whatever...and there is vi. Freedom of choice does strange things, doesn't it?

change log

[m()p3s]

The change log;
----------------
This section is about improvements made between version 6.3 and 6.4.

This is a bug-fix release. There are also a few new features. The major number of new items is in the runtime files and translations.

The big MS-Windows version now uses:
Ruby version 1.8.3
Perl version 5.8.7
Python version 2.4.2

Changed *changed-6.4*
-------

Removed runtime/tools/tcltags, Exuberant ctags does it better.

Added *added-6.4*
-----
Alsaconf syntax file (Nikolai Weibull)
Eruby syntax, indent, compiler and ftplugin file (Doug Kearns)
Esterel syntax file (Maurizio Tranchero)
Mathematica indent file (Steve Layland)
Netrc syntax file (Nikolai Weibull)
PHP compiler file (Doug Kearns)
Pascal indent file (Neil Carter)
Prescribe syntax file (Klaus Muth)
Rubyunit conpiler file (Doug Kearns)
SMTPrc syntax file (Kornel Kielczewski)
Sudoers syntax file (Nikolai Weibull)
TPP syntax file (Gerfried Fuchs)
VHDL ftplugin file (R. Shankar)
Verilog-AMS syntax file (S. Myles Prather)

Bulgarian keymap (Alberto Mardegan)
Canadian keymap (Eric Joanis)

Hungarian menu translations in UTF-8 (Kantra Gergely)
Ukrainian menu translations (Bohdan Vlasyuk)

Irish message translations (Kevin Patrick Scannell)

Configure also checks for tclsh8.4.

Fixed *fixed-6.4*
-----
"dFxd;" deleted the character under the cursor, "d;" didn't remember the exclusiveness of the motion.

When using "set laststatus=2 cmdheight=2" in the .gvimrc you may only get one line for the cmdline. (Christian Robinson) Invoke command_height() after the GUI has started up.

Gcc would warn "dereferencing type-punned pointer will break strict -aliasing rules". Avoid using typecasts for variable pointers.

Gcc 3.x interprets the -MM argument differently. Change "-I /path" to "-isystem /path" for "make depend".

Patch 6.3.001
Problem: ":browse split" gives the file selection dialog twice. (Gordon Bazeley) Same problem for ":browse diffpatch".
Solution: Reset cmdmod.browse before calling do_ecmd().
Files: src/diff.c, src/ex_docmd.c

Patch 6.3.002
Problem: When using translated help files with non-ASCII latin1 characters in the first line the utf-8 detection is wrong.
Solution: Properly detect utf-8 characters. When a mix of encodings is detected continue with the next language and avoid a "no matches" error because of "got_int" being set. Add the directory name to the error message for a duplicate tag. Files: src/ex_cmds.c

Patch 6.3.003
Problem: Crash when using a console dialog and the first choice does not have a default button. (Darin Ohashi)
Solution: Allocate two more characters for the [] around the character for the default choice.
Files: src/message.c

Patch 6.3.004
Problem: When searching for a long string (140 chars in a 80 column terminal) get three hit-enter prompts. (Robert Webb)
Solution: Avoid the hit-enter prompt when giving the message for wrapping around the end of the buffer. Don't give that message again when the string was not found.
Files: src/message.c, src/search.c

Patch 6.3.005
Problem: Crash when searching for a pattern with a character offset and starting in a closed fold. (Frank Butler)
Solution: Check for the column to be past the end of the line. Al

Re:A Year?

[Fujisawa Sensei]

Have been using Vim for more than 10 years now. This whole '"open "source thing' as you call it seems to be working much better for than the closed source alternatives. I have used vim under Windows, Linux, Solaris, Amiga OS, and NetBSD. Yup its working.

emacs and vim are too difficult to use

[MichaelSmith]

Neither of these two editors works like the sort of editor which people are exposed to these days. Why do you have to have an insert mode? This "feature" came from vi but for me it is exactly like bolting primitive editing behaviors on to more or less

In my day job as a senior programmer I introduce new staff to nedit. I also tell them to make their own choices about the tools they use. Most continue to use nedit because it has a few simple features which enhance usability. For example each function has a menu item, and each menu item tells you which key to use as an alternate way to reach the function. You don't have to worry about which mode it is in. Simple standard actions like opening and closing a file work in exactly the same way as other editors like gedit.

So for me people use vi(m) and emacs out of habit. Unless these tools improve they have no serious future in competition with eclipse, etc. Neither does nedit, for that matter but it will at least provide a better option for people new to *nix.

Re:emacs and vim are too difficult to use

[oneandoneis2]

Why do you have to have an insert mode? This "feature" came from vi but for me it is exactly like bolting primitive editing behaviors on to more or less

Try this: Go into Microsoft Windows, press the "Alt" button once, and then try to type Hello, world.

Funnily enough, instead of the key presses resulting in text going into the document, it'll navigate the menus. Why? Because it's just gone from Insert mode to a Command mode. It's exactly the same principle as Vi - sometimes you want key presses to result in text on the screen, and sometimes you want it to do something. It's not "primitive editing behaviour", it's exactly the same behaviour as is used in the most advanced word processors available. (And MS Word as well ;o) It's just not a visible, GUI-based Command mode in vi, is all.

So for me people use vi(m) and emacs out of habit.

I don't - I came to Linux a few years ago, needed a text editor, tried a few and settled on vi. Well, vim actually. It's a really good text editor once you learn it.

Vim can't do exorcisms...

[csirac]

~
:help the damned
~
E149: Sorry, no help for the damned                           0,0-1         All

:-(

Re:Bugggg fix only. nice

[m50d]

No no no. The features are being added in the 7.x branch, which you can get from CVS. 6.x is purely for maintenance (ie bugfixes). This is a mixed blessing... It means 6.x is extremely stable, but if you want new goodies like spellchecking and intelligent autocompletion, you have to switch to the CVS only branch.

For a piece of basic system software, it's more important that there's a stable branch that's actually stable. Now if only Linus would see things this way.

Vim source code

[chrysalis]

int main(void)
{
for(;;) {
get_keystroke();
bell();
flash_screen();
}
return 0; /* NOTREACHED */
}

Re:A vim library?

[sashang]

yes. http://www.yzis.org/

Re:From a newer Linux user's POV

[FishandChips]

You have a strong point. But even if you never need vi/vim or emacs it is still a really good idea to have a text editor available on Linux that you can use from the console. You can use it to edit configuration files and, more important, you can use it if you suffer a foobar and lose your graphical display (x-server), for example. So in that sense, a basic text editor is rather like keeping a fire extinguisher around. You may only use it once a year but boy you will be glad you have one.

A very simple one is nano/pico. A good intermediate one (does more than nano/pico but a lot less than vim/emacs) is joe. Being able to use joe has got me out of fixes on quite a few occasions now.

Re:A vim library?

[klap]

that's exactly what we are doing with Yzis ;)
we have a core library that manages the whole 'editing' aspect, syntax highlight, plugins, language bindings, configuration .... , and GUIs 'clients' that just sends inputs and displays outputs.
for now we have a KDE kpart (for kdevelop for example), a KDE app, a ncurses (console mode) and a Qt-only GUIs (will be used for windows and Mac OS X).
we have started a GTKmm based one but we are lacking people knowing gtk well to complete it.
windows port (and Mac OS X) is on the way and should be avail quite soon.

we are growing slowly but we should be able to release a stable initial release within a year.

any help is welcome :)

Mik, Yzis developer

Also, write code that can be understood.

[Poromenos1]

Autocompletion is not meant (at least as I perceive it) to help you remember the names of functions (although it's a big help there). It's meant to make you type the names faster, which can be a GODSEND if you use names like "intDocumentClassFontState" (overkill, but you get the meaning, and I know using prefixes in dynamically typed languages is wrong, but I like it). I want to be able to read my code when I look at it after having forgotten what it's about. Comments help, but they can only get you so far if your variable names are x, y, z.

Last Of The Well Behaved Editors

[vigilology]

Sorry if this rant is misplaced, but I see this as not an insignificant problem amongst newer GUI editors today.

There seems to be a growing (or at least more and more visible) practise of editors (especially GUI editors) not including EOL at the end of every line. They treat it as a line separator, not a line terminator, resulting in no EOL at the end of the last line.

Because of this, they also display lines incorrectly. I have noticed it with the editors in ZDE, Eclipse, and Scite. It only serves to create confusion when they interpret an EOL as 'start a new line', and actually start to display another line as if it already existed. This is very visible if you create a 'proper' text file you'll have to use a well-behaved text editor like vim for this) and open it in one of the above editors. It will display an extra line below the real last line of the file. You see something like this:

1 first line
2 middle line
3 last line
4

There are actually three lines in the text file and you can confirm this with 'wc -l '.

There is a lot of confusion with people who don't understand the concept of EOL and what these editors are doing. For example, I have people at work who use ZDE and when they open a text file created by me (vim), they go bonkers because they think I've put an extra blank line at the bottom of my scripts. There have been problems in the past with people really putting unnecessary blank lines at the bottom of scripts, and of course this lead to premature headers errors. Naturally, they think I'm doing the same, because they don't realise that their editor is displaying the file incorrectly.

I have one colleague who even wrote into our 'coding guidelines' recommending people not use vim because "it puts in extra characters that you don't ask for".

I have noticed that Redhat's default emacs configuration (FC3 at least) also opens text files in binary mode by default, resulting in a missing EOL on the last line of a newly created text file.

I'd like to know if I have the wrong idea about anything, but the question remains: what is the reason for these editors behaving this way?

Re:Last Of The Well Behaved Editors

[TuataraShoes]

If I had the points, I'd mod you up. I'm not familiar with ZDE or Scite, but I work with data transferred between different companies with a variety of systems. We end up writing custom adapter scripts to correct this kind of data format. End of line and end of file characters and character sequences are not universally standard. But sometimes they are completely and uniquely querky.

I don't mind that so much. What winds me up is when they ask us to write export adaptor scripts to screw the data up again to their preferred screwed-format as we return files to them!

Re: Vi Modes Considered Harmful

[some guy I know]

No one says vim is user friendly. It's not supposed to be.

Actually, when vi was first released, it was very user-friendly, at least compared to the default editor ed, which is a line editor, and which was generally the only other text editor available on most UNIX systems.
(If you want to compare the two, type "ed <some file>" at the command prompt on most *IX systems (including cygwin under MS-Windows), and try to edit the file.
Vi(m) is so much better.)
Even when editing on a DECWriter (a hard-copy terminal popular back in ancient times), I preferred using ex, the one-dimensional version of vi, to using ed.

Vi has held up surprisingly well over the last couple of decades, and (g)vim's added capabilities have made it even better.
(I really like the '*' and '#' commands, and being able to use the mouse and arrow keys in insert mode.
Oh, split-screen mode.
Etc., etc.)
Vi has done a decent job making the transition from TTY to GUI.

The one thing that annoys me sometimes is when I accidentally try to use vi commands in a non-vi setting.
For example, more than once I have accidentally dismissed a dialog box after filling in a text box because I hit the escape key to terminate insert mode.

Re:From a newer Linux user's POV

[peterpi]

New users shouldn't be using vim.

This might sound like a really elitist thing to say, but if the thought of spending a day or so learning it puts people off vim, then they probably wouldn't get the benefits anyway. I edit code all day every day, so the week or so it took me to learn what I know has been paid back many times over. The rest of the linux world might be going for ease of learning in order to increase the userbase, but vim isn't.

There are plenty of more intuitive editors out there that are probably far more suited to their needs. Kate for KDE is quite nice. Vim is a niche power-user's tool that fills a particular gap.