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

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

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.

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.

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.

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: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.

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?