Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Vim 6.4 Released

ScuttleMonkey posted more than 8 years ago | from the favorite-longtime-friends dept.

Programming 419

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.

cancel ×

419 comments

Sorry! There are no comments related to the filter you selected.

Why are we hiding from the police, daddy? (5, Funny)

(1+-sqrt(5))*(2**-1) (868173) | more than 8 years ago | (#13807021)

"Because we use vi [io.com] , son; they use emacs."

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

Re:Why are we hiding from the police, daddy? (1, Funny)

Anonymous Coward | more than 8 years ago | (#13807062)

yep, it's quite unfortunate that we still have discrimination due to the editor that one uses.

People are being taken from their homes and put in concentration camps, just because they use vim. Never heard of this you say? it's happening all over europe. The evil facist GNU are rounding them up in an attempt to rid the world of vim blood to wipe out the next generation.

I say screw them, stick up for your beliefs, and spread the words: 'vive la vim'

Re:Why are we hiding from the police, daddy? (3, Informative)

LnxAddct (679316) | more than 8 years ago | (#13807228)

The vimspell script works well.
Regards,
Steve

Vim still not as good as Notepad (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13807315)

At least Notepad has mouse support and word-wrap. Hopefully Vim 7 will address these issues.

Re:Why are we hiding from the police, daddy? (5, Funny)

falzer (224563) | more than 8 years ago | (#13807407)

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.

I just want to say thanks. (5, Insightful)

CyricZ (887944) | more than 8 years ago | (#13807024)

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. (1)

grasshoppa (657393) | more than 8 years ago | (#13807118)

Indeed. It wasn't until I found myself 5 pages into a web app that I realized I was using vim, and I was moving faster than my traditional windows based ide.

They deserve a huge pat on the back.

Re:I just want to say thanks. (4, Informative)

p2sam (139950) | more than 8 years ago | (#13807191)

Vim is charity-ware, please donate.

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

Re:I just want to say thanks. (0, Troll)

IWannaBeAnAC (653701) | more than 8 years ago | (#13807380)

Umm, what does that site have to do with vim ?

Re:I just want to say thanks. (3, Informative)

CodeRx (31888) | more than 8 years ago | (#13807310)

Bram is now taking donations [vim.org] 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.

What tha FUCK? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13807362)

This has got to be one of the most pathetic, content-free, karma whoring, failed first post attempts I have ever witnessed. Please mod this guy down as soon as possible. Thanks.

My thoughts on the matter (-1, Troll)

CodeMayhem (923421) | more than 8 years ago | (#13807033)

I fucked your mother

I fucked your mother
I fucked your mother


And your sister sucked my cock

Re:My thoughts on the matter (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13807125)

I certainly understand why you did what you did.

I've seen your mother and she is butt ugly . I understand she tied a porkchop around her neck long enough to force mate with a Schnauzer and you're the offspring.

Bugggg fix only. nice (3, Funny)

poind3xt3r (890661) | more than 8 years ago | (#13807035)

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.

That's not surprising. (2, Insightful)

CyricZ (887944) | more than 8 years ago | (#13807059)

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.

Re:That's not surprising. (1)

el americano (799629) | more than 8 years ago | (#13807313)

If you live in Windows land, XP is the major release and SP1, 2, 3, ... are the point fixes. Introducing regressions AND backward incompatible features. The all-bug-fix release is indeed a refreshing contrast.

Re:Bugggg fix only. nice (5, Informative)

keesh (202812) | more than 8 years ago | (#13807156)

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.

A Year? (-1, Flamebait)

sljgh (742290) | more than 8 years ago | (#13807037)

A year to release a new version and there's not even any new features? Yeah this whole "open source" thing is really gonna take off.

Re:A Year? (2, Insightful)

Spit (23158) | more than 8 years ago | (#13807053)

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.

Re:A Year? (1)

keesh (202812) | more than 8 years ago | (#13807126)

Then you might want to look at vim 7, which is where all the features are going. Spell checking, intelligent autocompletion, a hell of a lot of new tweaks that make vim even nicer to work with.

The 6.x branch is in 'maintenance mode', meaning it's bugfixes only. The 7.x branch is where all the work's going on, and vim 6 to vim 7 is already like going from vi to vim.

Re:A Year? (1)

DaCool42 (525559) | more than 8 years ago | (#13807162)

There have been a lot of great features added in the past few years. Here's a few of the major ones: folding, improved syntax highlighting, quickfix.

Might have taken a while.... (2, Funny)

ELiTe185 (923235) | more than 8 years ago | (#13807045)

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

Re:Might have taken a while.... (1)

NetRAVEN5000 (905777) | more than 8 years ago | (#13807166)

Microsoft only fixes security holes, not bugs.

Re:Might have taken a while.... (1)

wraithgar (317805) | more than 8 years ago | (#13807401)

> Microsoft only fixes security holes, not bugs.

That is because none of their stuff HAS bugs, just undocumented features.

Intellisense #1 feature, pay Bram to add it (4, Interesting)

Morganth (137341) | more than 8 years ago | (#13807066)

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 [vim.org]

Only if they find a good way of doing it. (1)

CyricZ (887944) | more than 8 years ago | (#13807081)

Indeed, finding out a "nice" way of doing it is essential. Nothing is more of a hassle than having Eclipse or the Visual Studio IDE autocomplete a keyword, identifier, and so on, incorrectly. Going back and correcting its error can take three or four times the amount of time it would've taken to type in the text manually.

At least it's possible that it would not be enabled by default.

Re:Only if they find a good way of doing it. (0)

Anonymous Coward | more than 8 years ago | (#13807348)

Nothing is more of a hassle than having Eclipse or the Visual Studio IDE autocomplete a keyword, identifier, and so on, incorrectly.

Except perhaps using an editor without Intellisense and having to manually nagivate through pages upon pages of docs (or, God forbid, raw uncommented code) every time you want to figure out what functions an object has, or what the name of that namespace is, or whether that variable is camel case or underscored, or the order of that function's arguments. Which takes up more and more programmer time as we move toward using more and more libraries, each consisting of hundreds to thousands of functions. Today when you're building complex componentized software it's impossible to memorize every API call you need like you could in the "good" old days, back when vi was modern.

Re:Intellisense #1 feature, pay Bram to add it (0, Informative)

Anonymous Coward | more than 8 years ago | (#13807175)

viPlugin is a commercial (but cheap) plugin that adds a vim layer on top of standard eclipse editors. While it does have some bugs, problems with some editors, and doesn't do everything vim does, it does have the basic command, visual, insert mode functionality that I can't live without.

http://www.satokar.com/viplugin/index.php [satokar.com]

This plugin + eclipse is super productive (for me, anyway) when writing java.

Re:Intellisense #1 feature, pay Bram to add it (5, Informative)

kaisyain (15013) | more than 8 years ago | (#13807247)

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 (1)

cryptoluddite (658517) | more than 8 years ago | (#13807285)

I'd actually like to see a Java port of vim. I looked at the source code and it doesn't seem too hard. The vast majority of code is ifdef's for various architectures; this could all be replaced with one straight implementation in Java. The rest of the code seems fairly well encapsulated in object-like structures, so it should be somewhat easy.

This would make integrating jvim into eclipse and adding intellisense into it much easier. Of course it would be slower and hunkier, but it would still be cool to see all that code in Java. It would make a fun port imo.

hats off to Bram, Bill Joy, and ATT (5, Interesting)

yagu (721525) | more than 8 years ago | (#13807071)

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

Not only is it a fantastic editor... (4, Interesting)

CyricZ (887944) | more than 8 years ago | (#13807134)

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

please mod up parent (0)

Anonymous Coward | more than 8 years ago | (#13807211)

pseudo-mod: "+1 Interesting" -- good point

Re:Not only is it a fantastic editor... (1)

jZnat (793348) | more than 8 years ago | (#13807216)

I thought less was made in an effort to emulate vim in a sense as well. At least, that's what its manpage says.

Re:Not only is it a fantastic editor... (1)

CyricZ (887944) | more than 8 years ago | (#13807223)

Why use the half-assed less when you have have the real VIM? The memory requirement differences between the two are basically irrelevant these days, and speedwise they're indistinguishable.

Re:Not only is it a fantastic editor... (1, Insightful)

Anonymous Coward | more than 8 years ago | (#13807357)

So you're saying that you've never needed to paginate piped input?

Re:Not only is it a fantastic editor... (0)

Anonymous Coward | more than 8 years ago | (#13807364)

I use both vim and less. One issue is that vim's key mappings are optimized for editing, where those of less are optimized for browsing. For example, in less j and k scroll the window by one, and f and b do pageup/pagedown. In vim, j and k move the cursor, (which isn't really very useful in a pager), and you have to use the more difficult ^E and ^Y to scroll the page instead. You also have to hit ^F and ^B to page up and down, because f and b are mapped to more cursor movement commands. The q command in less is also far easier to type than either :q or ZQ.

Then there's the general problem that many of the keys in vim are mapped to editing commands that modify the file, so accidentally hitting a random key will likely give a warning message about modifying a read-only file and require an undo operation.

Re:Not only is it a fantastic editor... (4, Funny)

Tumbleweed (3706) | more than 8 years ago | (#13807403)

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

Re:hats off to Bram, Bill Joy, and ATT (1)

scooviduvoctagon (801935) | more than 8 years ago | (#13807195)

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

Never let that happen again, use yzis and konqueror: http://yzis.org.free.fr/shots/khtml-textarea.jpg [org.free.fr]

Re:hats off to Bram, Bill Joy, and ATT (1)

chrysrobyn (106763) | more than 8 years ago | (#13807208)

Editor faceoffs. I've won several of those with vi on my belt. When we get to use the whole toolkit, I'll often whip out some temp files and use awk a bit (for column processing). I've got two questions for someone out there with better vi skills than I.

How would a vi pro do CSV test processing? How would you take the text between the second and third commas and replace it with arbitrary text?

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? vi is very straightforward, so I assume I'll be able to understand only replacing "wxyz" in the 20th through 23rd column with "abcd".

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.

Too many people forget: "vi is power".

Re:hats off to Bram, Bill Joy, and ATT (1)

ScriptedReplay (908196) | more than 8 years ago | (#13807379)

I'm sure there's a better way to do these, but here's a try off the top of a vim noob:

How would you take the text between the second and third commas and replace it with arbitrary text?
:%s/\(\([^,]*,\)\{2}\)[^,]*\(,.*\)$/\1arbitrary text\3/gc

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?
:%s/^\(.\{19}\).\{4}\(.*\)$/\1abcd\2/gc

Please feel free to correct me/improve on this. New vim tricks are always appreciated :-)

Re:hats off to Bram, Bill Joy, and ATT (1)

morcego (260031) | more than 8 years ago | (#13807412)

Actually, you don't need to match anything after what you want to replace, neither use "gc". Even "g" is not needed, since you will only replace 1 occurence on each line.

Check my exemple a few posts below, even tho I do use "g" there.

The most simple command for this would be: :%s@^\(.\{19\}).\{4\}@\1abcd@

I also like to use @ instead of /, since it makes it easier to read.

Re:hats off to Bram, Bill Joy, and ATT (1)

b17bmbr (608864) | more than 8 years ago | (#13807394)

How would a vi pro do CSV test processing?

with a perl script. written on vim of course!!

Re:hats off to Bram, Bill Joy, and ATT (2, Informative)

morcego (260031) | more than 8 years ago | (#13807398)

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 (1)

bypedd (922626) | more than 8 years ago | (#13807209)

Agreed. I am a little embarassed to say it was only about a month ago I started using ViM as opposed to vi, but I do love me a good ViM-tweaking session. Very gratifying :) And yet, the number one feature, to me, has always been the, well, vi commands. The escape mode and the hjkl navigation. I would use any IDE or editor in a minute if it would offer just the absolute basic vi features.

Re:hats off to Bram, Bill Joy, and ATT (4, Interesting)

trb (8509) | more than 8 years ago | (#13807305)

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 (1)

yagu (721525) | more than 8 years ago | (#13807381)

Yes, I agree, there are more to thank. I was using "ed" when I was introduced to "sc". And I even used qed.

And, did you read, and do you still have your copy of that BSD book, kind of a paperback (with the plastic spine binding), with all of the papers (an odd book, but one of the most useful I'd ever read), including lots of good stuff on nroff, etc? There were more than one, but the one I'm thinking of had a cartoon of a devil (if I remember correctly) poking at "unix" with his trident from behind a rock. Great book. (Now I'm going to have to go find it -- I know I never threw that one away.)

Lots of bug fixes (-1, Offtopic)

dtfinch (661405) | more than 8 years ago | (#13807076)

Unfortunately, you'll have to install the newest version and type :help version-6.4 to learn what those fixes are, to learn why you just took the time to download, compile, and install a vim update.

Re:Lots of bug fixes (1)

ploss (860589) | more than 8 years ago | (#13807355)

But only if you use Gentoo :)

Re:Lots of bug fixes (0, Offtopic)

Cheapy (809643) | more than 8 years ago | (#13807369)

I can't help but wonder why this post got modded Off Topic...

Yes, but is it better than emacs?? (0, Redundant)

borgheron (172546) | more than 8 years ago | (#13807079)

Hehe. Obligatory emacs comment here. 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. I wonder if any of the VIM developers use emacs to develop VIM. :)

GJC

Re:Yes, but is it better than emacs?? (2)

CyricZ (887944) | more than 8 years ago | (#13807087)

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?? (2, Funny)

Hamster Of Death (413544) | more than 8 years ago | (#13807089)

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?? (1)

geminidomino (614729) | more than 8 years ago | (#13807136)

Some people like knowing the editor that is 99% certain to be available.
Some people don't like using six of their 8 home-key fingers, plus nose and tongue, to toggle buckybits.
Some people would rather have a 1.5MB editor than a 40+MB monstrosity taking up pr0n space.

(Swami Salami says: "Some people don't have a sense of humor", in response to the future downmodding storm by cranky EMACS users.)

Eighty Megs and Constantly Swapping!

Re:Yes, but is it better than emacs?? (1)

bcrowell (177657) | more than 8 years ago | (#13807246)

Some people like knowing the editor that is 99% certain to be available.
Well, yeah, when I do a fresh install of Linux, emacs is unavailable for the first 23 seconds after the unstall is complete :-)

Some people don't like using six of their 8 home-key fingers, plus nose and tongue, to toggle buckybits.
It does baffle me that some people use Esc for meta. I just use Alt.

Some people would rather have a 1.5MB editor than a 40+MB monstrosity taking up pr0n space.
For people who want something small, there are various trimmed down emacs versions, such as zile.

Re:Yes, but is it better than emacs?? (2, Funny)

ocelotbob (173602) | more than 8 years ago | (#13807268)

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

Re:Yes, but is it better than emacs?? (1)

mabinogi (74033) | more than 8 years ago | (#13807149)

> Some people grow attached to their pointy sticks and stone hammer tools when building a sub par house.
and everyone else uses Vim.

Re:Yes, but is it better than emacs?? (1)

mnemonic_ (164550) | more than 8 years ago | (#13807090)

I wonder if any of the VIM developers use emacs to develop VIM.

Well I used to wonder what the absolute limit of stupidity wass, but no longer. I think I've found it.

Re:Yes, but is it better than emacs?? (1)

CyricZ (887944) | more than 8 years ago | (#13807114)

Gregory John Casamento is not a stupid man by any means. Indeed, he is responsible for some amazing work. Take Gorm, for example. It brings the cutting edge development techniques of NeXT to Linux and other non-NeXT/non-Apple systems.

Have both. (1)

tepples (727027) | more than 8 years ago | (#13807103)

Try viper-mode. Love viper-mode. Then try Vim. It's viper-mode without the bloat.

Re:Yes, but is it better than emacs?? (5, Insightful)

rebug (520669) | more than 8 years ago | (#13807104)

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?

Re:Yes, but is it better than emacs?? (0, Troll)

Anonymous Coward | more than 8 years ago | (#13807147)

Notepad is better than emacs. I could write code on paper, scan it in with my scanner using OCR, correct all the mistakes in MS Word, convert it to a .c file, and it would still be better than emacs. Talk about building a house with sticks and stone tools.

Re:Yes, but is it better than emacs?? (1)

arodland (127775) | more than 8 years ago | (#13807153)

Because it's not only faster, but easier on my hands? Two bits of state is not by any means too much to have to keep in my head. And in vim, you have the nice status bar to tell you where you are in case you went off somewhere and forgot. It'll even show you your half-finished normal-mode commands if you like. So overall it's faster and easier than, well, anything.

Re:Yes, but is it better than emacs?? (1)

ari_j (90255) | more than 8 years ago | (#13807239)

I wonder if any of the VIM developers use emacs to develop VIM.

I don't know, and I'm not a developer of Vim or Emacs, but I have hacked Emacs with vim.

Re:Yes, but is it better than emacs?? (1)

grcumb (781340) | more than 8 years ago | (#13807286)

"I have hacked Emacs with vim."

Heh, I had a giggle this morning when I checked my history file and found:

477 vi .emacs
478 vi .emacs
479 emacs&
...
507 vi .emacs

8^)

Re:Yes, but is it better than emacs?? (1)

blakestah (91866) | more than 8 years ago | (#13807253)

I wonder if any of the VIM developers use emacs to develop VIM.

Blatant troll response.

Yes, we all know that the BEST solution for a text editor requires a full LISP interpreter.

Re:Yes, but is it better than emacs?? (1)

YankeeInExile (577704) | more than 8 years ago | (#13807260)

Here's a little story that will make you realize how great emacs and vi(m) really are. http://www.gnu.org/fun/jokes/ed.msg.html [gnu.org]

Bug fixes (5, Funny)

patrickclay (898576) | more than 8 years ago | (#13807084)

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 (1)

jZnat (793348) | more than 8 years ago | (#13807230)

:w

Wow, ain't that hard?

Type "ZZ" to save and quit. Those are indeed capitalised, and Shift is right next to Z.

Re:Bug fixes (0, Flamebait)

dtfinch (661405) | more than 8 years ago | (#13807240)

I entirely agree. Editors like vi and emacs are decades behind the rest of the world in terms of usability and intuitiveness. Luckily, on a remote server I can always launch a modern text editor using X11 forwarding over ssh. I know just enough vi to type, search, save, and exit. If I hit q without hitting :, it switches to some recording mode and stops responding to normal commands. It I hit # when not in insert mode, it put a bright yellow highlight on whatever word the cursor was over, which persists even after I exit vi and start it again, until I manually edit the config file to delete the highlight keyword. I'm sure there are easy ways out of both problems, and the many others I've encountered, if I memorized the help file rather than just skimming it a few times, but I'd rather not spend any more time than I need to with such a backward piece of sh^Hoftware. I only use vi for very minor edits, like changing a single value in a config file. For everything else, I use a real text editor.

Re:Bug fixes (1)

tabbser (560130) | more than 8 years ago | (#13807325)

I'm happy with Vim. I use it all the time, it's my editor of choice. I've worked in many shops, some emacs and some vi, and heard all the religious comments about both (over the last 20 years)

I have to say that the above is probably the silliest I've heard in a long time though.
Just because you have not taken the time to learn either of these great editors, but instead are happy to pipe X over an SSH connection so you can 'point-click-drool', doesn't really qualify you to dismiss them.

You really don't need to learn much to make good headway on both these editors, you'll become a capable very quickly, assuming you have the capacity in you to begin with.

Also, it'll improve your sex life, make your cell phone battery last a month and you'll be able leap tall buildings in a single bound.

Re:Bug fixes (1)

darilon (752912) | more than 8 years ago | (#13807343)

Forget using the built in help files for vim. Just google up one of the many good quick tutorials that teach you the important things you need to know to use vi fairly effectively. After you've done that and used vim for any length of time you can learn how to be an efficient editor of text. By becoming a slave to gui based editors, you lose many of the efficiencies that you can get from text only editors.

Re:Bug fixes (2, Interesting)

Waffle Iron (339739) | more than 8 years ago | (#13807242)

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 (2, Informative)

dedazo (737510) | more than 8 years ago | (#13807319)

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.

I for one... (4, Funny)

_Hellfire_ (170113) | more than 8 years ago | (#13807109)

...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! (4, Funny)

earthbound kid (859282) | more than 8 years ago | (#13807116)

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

Re:That's nothing! (0)

Anonymous Coward | more than 8 years ago | (#13807221)

What? Still no flight simulator?

happy vomiting! (0)

Anonymous Coward | more than 8 years ago | (#13807131)

because I use vi.

Did someone mention the Fantastic Four? (4, Funny)

Rhinobird (151521) | more than 8 years ago | (#13807198)

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 (5, Interesting)

MrBoring (256282) | more than 8 years ago | (#13807224)

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 (3, Informative)

p2sam (139950) | more than 8 years ago | (#13807378)

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? (4, Interesting)

wk633 (442820) | more than 8 years ago | (#13807226)

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? (3, Informative)

Superfluid Blob (798525) | more than 8 years ago | (#13807243)

^Q

Re:How do you do a character literal? (1)

wk633 (442820) | more than 8 years ago | (#13807272)

THANK YOU! I don't know who modded me 'funny', and maybe I should be embarassed for having to ask, but you made my month!

And to keep this on topic, I'm surprised that nobody has mentioned that there is no editor more powerful than vi(m). The proof is that vi can be used to emulate a turing machine.

http://www.cs.brown.edu/people/jfh/personal_other/ amusements/hitz.html/ [brown.edu]

Re:How do you do a character literal? (1)

Superfluid Blob (798525) | more than 8 years ago | (#13807301)

Welcome :) Another nice tip: if you want to do some complicated search and replace, it's often a lot quicker to do :perldo s/foo/bar/ rather than remember the vim regexp syntax.

Re:How do you do a character literal? (1)

Slayk (691976) | more than 8 years ago | (#13807264)

It only pastes on Windows or if you have vim open in GNOME-Terminal (which overrides the vim keybinding), and I believe you can controll that by editing your _vimrc or in the case of gnome-term by changing the keybinding in the edit menu.

If what I just did in gvim is any indication, ^V works just peachy in Vim.

Re:How do you do a character literal? (1)

tootlemonde (579170) | more than 8 years ago | (#13807269)

what's the windows vim equivelent of vi's ^V?

That would be Ctrl-Q (while in insert mode or entering a search string)

Get rid of the default _vimrc (1)

matvei (568098) | more than 8 years ago | (#13807387)

I've replaced my Windows gvim's _vimrc with my hand-written .vimrc that I use everywhere I have a shell account, and I haven't noticed the behaviour you described. I'm quite sure that the default _vimrc sets an option that does that.

I thought Vim was a finished project (2, Insightful)

ravee (201020) | more than 8 years ago | (#13807229)

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

In a related story... (0, Flamebait)

flazz (905447) | more than 8 years ago | (#13807237)

a new version of emacs will never be released

VIM? (2, Funny)

thomble (642879) | more than 8 years ago | (#13807254)

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

ChangeLog? (1)

miknight (642270) | more than 8 years ago | (#13807273)

Does there exist a formal list of bugs that were actually fixed for vim? I've never been able to find one :S

Yipee! (3, Interesting)

callipygian-showsyst (631222) | more than 8 years ago | (#13807289)

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.

Need release faster (5, Funny)

2Bits (167227) | more than 8 years ago | (#13807320)

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 (5, Funny)

forkazoo (138186) | more than 8 years ago | (#13807402)

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... (4, Informative)

fm6 (162816) | more than 8 years ago | (#13807329)

... don't forget that it's charityware [vim.org] .

Maybe it is not interesting... (3, Insightful)

Pecisk (688001) | more than 8 years ago | (#13807353)

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?

I Love Vim (0)

Anonymous Coward | more than 8 years ago | (#13807384)

I just have to say that. For the enjoyment of other Vim fans, here are a few maps I created to ease writing and quitting:


# write the file with alt-w
map <silent> <M-w> :w<CR>
imap <silent> <M-w> <ESC><M-w>a

# quit the file with alt-q
map <silent> <M-q> :q<CR>
imap <silent> <M-q> <ESC><M-q>

change log (3, Informative)

m()p3s (888808) | more than 8 years ago | (#13807385)

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.  Also fix that a pattern with a character offset relative to the end isn't read back from the viminfo properly.
Files:        src/search.c

Patch 6.3.006
Problem:    ":breakadd file *foo" prepends the current directory to the file pattern. (Hari Krishna Dara)
Solution:   Keep the pattern as-is.
Files:        src/ex_cmds2.c

Patch 6.3.007
Problem:    When there is a buffer with 'buftype' set to "nofile" and using a ":cd" command, the swap file is not deleted when exiting.
Solution:   Use the full path of the swap file also for "nofile" buffers.
Files:        src/fileio.c

Patch 6.3.008
Problem:    Compiling fails under OS/2.
Solution:   Include "e_screenmode" also for OS/2. (David Sanders)
Files:        src/globals.h

Patch 6.3.009 (after 6.3.006)
Problem:    ":breakadd file /path/foo.vim" does not match when a symbolic link is involved.  (Servatius Brandt)
Solution:   Do expand the pattern when it does not start with "*".
Files:        runtime/doc/repeat.txt, src/ex_cmds2.c

Patch 6.3.010
Problem:    When writing to a named pipe there is an error for fsync() failing.
Solution:   Ignore the fsync() error for devices.
Files:        src/fileio.c

Patch 6.3.011
Problem:    Crash when the completion function of a user-command uses a "normal :cmd" command.  (Hari Krishna Dara)
Solution:   Save the command line when invoking the completion function.
Files:        src/ex_getln.c

Patch 6.3.012
Problem:    Internal lalloc(0) error when using a complicated multi-line pattern in a substitute command. (Luc Hermitte)
Solution:   Avoid going past the end of a line.
Files:        src/ex_cmds.c

Patch 6.3.013
Problem:    Crash when editing a command line and typing CTRL-R = to evaluate a function that uses "normal :cmd". (Hari Krishna Dara)
Solution:   Save and restore the command line when evaluating an expression for CTRL-R =.
Files:        src/ex_getln.c, src/ops.c, src/proto/ex_getln.pro,
        src/proto/ops.pro

Patch 6.3.014
Problem:    When using Chinese or Taiwanese the default for 'helplang' is wrong. (Simon Liang)
Solution:   Use the part of the locale name after "zh_".
Files:        src/option.c

Patch 6.3.015
Problem:    The string that winrestcmd() returns may end in garbage.
Solution:   NUL-terminate the string. (Walter Briscoe)
Files:        src/eval.c

Patch 6.3.016
Problem:    The default value for 'define' has "\s" before '#'.
Solution:   Add a star after "\s". (Herculano de Lima Einloft Neto)
Files:        src/option.c

Patch 6.3.017
Problem:    "8zz" may leave the cursor beyond the end of the line. (Niko Maatjes)
Solution:   Correct the cursor column after moving to another line.
Files:        src/normal.c

Patch 6.3.018
Problem:    ":0argadd zero" added the argument after the first one, instead of before it. (Adri Verhoef)
Solution:   Accept a zero range for ":argadd".
Files:        src/ex_cmds.h

Patch 6.3.019
Problem:    Crash in startup for debug version. (David Rennals)
Solution:   Move the call to nbdebug_wait() to after allocating NameBuff.
Files:        src/main.c

Patch 6.3.020
Problem:    When 'encoding' is "utf-8" and 'delcombine' is set, "dw" does not delete a word but only a combining character of the first character, if there is one. (Raphael Finkel)
Solution:   Correctly check that one character is being deleted.
Files:        src/misc1.c

Patch 6.3.021
Problem:    When the last character of a file name is a multi-byte character and the last byte is a path separator, the file cannot be edited.
Solution:   Check for the last byte to be part of a multi-byte character. (Taro Muraoka)
Files:        src/fileio.c

Patch 6.3.022 (extra)
Problem:    Win32: When the last character of a file name is a multi-byte character and the last byte is a path separator, the file cannot be written.  A trail byte that is a space makes that a file cannot be opened from the command line.
Solution:   Recognize double-byte characters when parsing the command line. In mch_stat() check for the last byte to be part of a multi-byte character. (Taro Muraoka)
Files:        src/gui_w48.c, src/os_mswin.c

Patch 6.3.023
Problem:    When the "to" part of a mapping starts with its "from" part,  abbreviations for the same characters is not possible.  For example, when <Space> is mapped to something that starts with a space, typing <Space> does not expand abbreviations.
Solution:   Only disable expanding abbreviations when a mapping is not remapped, don't disable it when the RHS of a mapping starts with the LHS.
Files:        src/getchar.c, src/vim.h

Patch 6.3.024
Problem:    In a few places a string in allocated memory is not terminated with a NUL.
Solution:   Add ga_append(NUL) in script_get(), gui_do_findrepl() and serverGetVimNames().
Files:        src/ex_getln.c, src/gui.c, src/if_xcmdsrv.c, src/os_mswin.c

Patch 6.3.025 (extra)
Problem:    Missing NUL for list of server names.
Solution:   Add ga_append(NUL) in serverGetVimNames().
Files:        src/os_mswin.c

Patch 6.3.026
Problem:    When ~/.vim/after/syntax/syncolor.vim contains a command that reloads the colors an endless loop and/or a crash may occur.
solution:   Only free the old value of an option when it was originally allocated.  Limit recursiveness of init_highlight() to 5 levels.
Files:        src/option.c, src/syntax.c

Patch 6.3.027
Problem:    VMS: Writing a file may insert extra CR characters.  Not all terminals are recognized correctly.  Vt320 doesn't support colors. Environment variables are not expanded correctly.
Solution:   Use another method to write files.  Add vt320 termcap codes for colors.  (Zoltan Arpadffy)
Files:        src/fileio.c, src/misc1.c, src/os_unix.c, src/structs.h, src/term.c

Patch 6.3.028
Problem:    When appending to a file the BOM marker may be written.  (Alex Jakushev)
Solution:   Do not write the BOM marker when appending.
Files:        src/fileio.c

Patch 6.3.029
Problem:    Crash when inserting a line break. (Walter Briscoe)
Solution:   In the syntax highlighting code, don't use an old state after a change was made, current_col may be past the end of the line.
Files:        src/syntax.c

Patch 6.3.030
Problem:    GTK 2: Crash when sourcing a script that deletes the menus, sets 'encoding' to "utf-8" and loads the menus again.  GTK error message when tooltip text is in a wrong encoding.
Solution:   Don't copy characters from the old screen to the new screen when switching 'encoding' to utf-8, they may be invalid.  Only set the tooltip when it is valid utf-8.
Files:        src/gui_gtk.c, src/mbyte.c, src/proto/mbyte.pro, src/screen.c

Patch 6.3.031
Problem:    When entering a mapping and pressing Tab halfway the command line isn't redrawn properly. (Adri Verhoef)
Solution:   Reposition the cursor after drawing over the "..." of the completion attempt.
Files:        src/ex_getln.c

Patch 6.3.032
Problem:    Using Python 2.3 with threads doesn't work properly.
Solution:   Release the lock after initialization.
Files:        src/if_python.c

Patch 6.3.033
Problem:    When a mapping ends in a Normal mode command of more than one character Vim doesn't return to Insert mode.
Solution:   Check that the mapping has ended after obtaining all characters of the Normal mode command.
Files:        src/normal.c

Patch 6.3.034
Problem:    VMS: crash when using ":help".
Solution:   Avoid using "tags-??", some Open VMS systems can't handle the "?" wildcard.  (Zoltan Arpadffy)
Files:        src/tag.c

Patch 6.3.035 (extra)
Problem:    RISC OS: Compile errors.
Solution:   Change e_screnmode to e_screenmode.  Change the way
        __riscosify_control is set.  Improve the makefile.  (Andy Wingate)
Files:        src/os_riscos.c, src/search.c, src/Make_ro.mak

Patch 6.3.036
Problem:    ml_get errors when the whole file is a fold, switching 'foldmethod' and doing "zj". (Christian J. Robinson) Was not  deleting the fold but creating a fold with zero lines.
Solution:   Delete the fold properly.
Files:        src/fold.c

Patch 6.3.037 (after 6.3.032)
Problem:    Warning for unused variable.
Solution:   Change the #ifdefs for the saved thread stuff.
Files:        src/if_python.c

Patch 6.3.038 (extra)
Problem:    Win32: When the "file changed" dialog pops up after a click that gives gvim focus and not moving the mouse after that, the effect of the click may occur when moving the mouse later. (Ken Clark) Happened because the release event was missed.
Solution:   Clear the s_button_pending variable when any input is received.
Files:        src/gui_w48.c

Patch 6.3.039
Problem:    When 'number' is set and inserting lines just above the first displayed line (in another window on the same buffer), the line numbers are not updated.  (Hitier Sylvain)
Solution:   When 'number' is set and lines are inserted/deleted redraw all lines below the change.
Files:        src/screen.c

Patch 6.3.040
Problem:    Error handling does not always work properly and may cause a buffer to be marked as if it's viewed in a window while it isn't. Also when selecting "Abort" at the attention prompt.
Solution:   Add enter_cleanup() and leave_cleanup() functions to move saving/restoring things for error handling to one place.
        Clear a buffer read error when it's unloaded.
Files:        src/buffer.c, src/ex_docmd.c, src/ex_eval.c,
        src/proto/ex_eval.pro, src/structs.h, src/vim.h

Patch 6.3.041 (extra)
Problem:    Win32: When the path to a file has Russian characters, ":cd %:p:h" doesn't work. (Valery Kondakoff)
Solution:   Use a wide function to change directory.
Files:        src/os_mswin.c

Patch 6.3.042
Problem:    When there is a closed fold at the top of the window, CTRL-X CTRL-E in Insert mode reduces the size of the fold instead of scrolling the text up. (Gautam)
Solution:   Scroll over the closed fold.
Files:        src/move.c

Patch 6.3.043
Problem:    'hlsearch' highlighting sometimes disappears when inserting text in PHP code with syntax highlighting. (Marcel Svitalsky)
Solution:   Don't use pointers to remember where a match was found, use an index.  The pointers may become invalid when searching in other lines.
Files:        src/screen.c

Patch 6.3.044 (extra)
Problem:    Mac: When 'linespace' is non-zero the Insert mode cursor leaves pixels behind. (Richard Sandilands)
Solution:   Erase the character cell before drawing the text when needed.
Files:        src/gui_mac.c

Patch 6.3.045
Problem:    Unusual characters in an option value may cause unexpected behavior, especially for a modeline. (Ciaran McCreesh)
Solution:   Don't allow setting termcap options or 'printdevice' in a modeline.  Don't list options for "termcap" and "all" in a
modeline.  Don't allow unusual characters in 'filetype', 'syntax', 'backupext', 'keymap', 'patchmode' and 'langmenu'.
Files:        src/option.c, runtime/doc/options.txt

Patch 6.3.046
Problem:    ":registers" doesn't show multi-byte characters properly. (Valery Kondakoff)
Solution:   Get the length of each character before displaying it.
Files:        src/ops.c

Patch 6.3.047 (extra)
Problem:    Win32 with Borland C 5.5 on Windows XP: A new file is created with read-only attributes. (Tony Mechelynck)
Solution:   Don't use the _wopen() function for Borland.
Files:        src/os_win32.c

Patch 6.3.048 (extra)
Problem:    Build problems with VMS on IA64.
Solution:   Add dependencies to the build file. (Zoltan Arpadffy)
Files:        src/Make_vms.mms

Patch 6.3.049 (after 6.3.045)
Problem:    Compiler warning for "char" vs "char_u" mixup. (Zoltan Arpadffy)
Solution:   Add a typecast.
Files:        src/option.c

Patch 6.3.050
Problem:    When SIGHUP is received while busy exiting, non-reentrant functions such as free() may cause a crash.
Solution:   Ignore SIGHUP when exiting because of an error. (Scott Anderson)
Files:        src/misc1.c, src/main.c

Patch 6.3.051
Problem:    When 'wildmenu' is set and completed file names contain multi-byte characters Vim may crash.
Solution:   Reserve room for multi-byte characters. (Yasuhiro Matsumoto)
Files:        src/screen.c

Patch 6.3.052 (extra)
Problem:    Windows 98: typed keys that are not ASCII may not work properly. For example with a Russian input method. (Jiri Jezdinsky)
Solution:   Assume that the characters arrive in the current codepage instead of UCS-2.  Perform conversion based on that.
Files:        src/gui_w48.c

Patch 6.3.053
Problem:    Win32: ":loadview" cannot find a file with non-ASCII characters. (Valerie Kondakoff)
Solution:   Use mch_open() instead of open() to open the file.
Files:        src/ex_cmds2.c

Patch 6.3.054
Problem:    When 'insertmode' is set <C-L>4ixxx<C-L> hangs Vim. (Jens Paulus) Vim is actually still working but redraw is disabled.
Solution:   When stopping Insert mode with CTRL-L don't put an Esc in the redo buffer but a CTRL-L.
Files:        src/edit.c

Patch 6.3.055 (after 6.3.013)
Problem:    Can't use getcmdline(), getcmdpos() or setcmdpos() with <C-R>= when editing a command line.  Using <C-\>e may crash Vim. (Peter Winters)
Solution:   When moving ccline out of the way for recursive use, make it available to the functions that need it.  Also save and restore ccline when calling get_expr_line().  Make ccline.cmdbuf NULL at the end of getcmdline().
Files:        src/ex_getln.c

Patch 6.3.056
Problem:    The last characters of a multi-byte file name may not be displayed in the window title.
Solution:   Avoid to remove a multi-byte character where the last byte looks like a path separator character. (Yasuhiro Matsumoto)
Files:        src/buffer.c, src/ex_getln.c

Patch 6.3.057
Problem:    When filtering lines folds are not updated. (Carl Osterwisch)
Solution:   Update folds for filtered lines.
Files:        src/ex_cmds.c

Patch 6.3.058
Problem:    When 'foldcolumn' is equal to the window width and 'wrap' is on Vim may crash.  Disabling the vertical split feature breaks compiling.  (Peter Winters)
Solution:   Check for zero room for wrapped text.  Make compiling without vertical splits possible.
Files:        src/move.c, src/quickfix.c, src/screen.c, src/netbeans.c

Patch 6.3.059
Problem:    Crash when expanding an ":edit" command containing several spaces with the shell. (Brian Hirt)
Solution:   Allocate enough space for the quotes.
Files:        src/os_unix.c

Patch 6.3.060
Problem:    Using CTRL-R CTRL-O in Insert mode with an invalid register name still causes something to be inserted.
Solution:   Check the register name for being valid.
Files:        src/edit.c

Patch 6.3.061
Problem:    When editing a utf-8 file in an utf-8 xterm and there is a multi-byte character in the last column, displaying is messed up. (Jo&#235;l Rio)
Solution:   Check for a multi-byte character, not a multi-column character.
Files:        src/screen.c

Patch 6.3.062
Problem:    ":normal! gQ" hangs.
Solution:   Quit getcmdline() and do_exmode() when out of typeahead.
Files:        src/ex_getln.c, src/ex_docmd.c

Patch 6.3.063
Problem:    When a CursorHold autocommand changes to another window (temporarily) 'mousefocus' stops working.
Solution:   Call gui_mouse_correct() after triggering CursorHold.
Files:        src/gui.c

Patch 6.3.064
Problem:    line2byte(line("$") + 1) sometimes returns the wrong number.
        (Charles Campbell)
Solution:   Flush the cached line before counting the bytes.
Files:        src/memline.c

Patch 6.3.065
Problem:    The euro digraph doesn't always work.
Solution:   Add an "e=" digraph for Unicode euro character and adjust the
        help files.
Files:        src/digraph.c, runtime/doc/digraph.txt

Patch 6.3.066
Problem:    Backup file may get wrong permissions.
Solution:   Use permissions of original file for backup file in more places.
Files:        src/fileio.c

Patch 6.3.067 (after 6.3.066)
Problem:    Newly created file gets execute permission.
Solution:   Check for "perm" to be negative before using it.
Files:        src/fileio.c

Patch 6.3.068
Problem:    When editing a compressed file xxx.gz which is a symbolic link to
        the actual file a ":write" renames the link.
Solution:   Resolve the link, so that the actual file is renamed and
        compressed.
Files:        runtime/plugin/gzip.vim

Patch 6.3.069
Problem:    When converting text with illegal characters Vim may crash.
Solution:   Avoid that too much is subtracted from the length. (Da Woon Jung)
Files:        src/mbyte.c

Patch 6.3.070
Problem:    After ":set number linebreak wrap" and a vertical split, moving
        the vertical separator far left will crash Vim. (Georg Dahn)
Solution:   Avoid dividing by zero.
Files:        src/charset.c

Patch 6.3.071
Problem:    The message for CTRL-X mode is still displayed after an error for
        'thesaurus' or 'dictionary' being empty.
Solution:   Clear "edit_submode".
Files:        src/edit.c

Patch 6.3.072
Problem:    Crash in giving substitute message when language is Chinese and
        encoding is utf-8. (Yongwei)
Solution:   Make the msg_buf size larger when using multi-byte.
Files:        src/vim.h

Patch 6.3.073
Problem:    Win32 GUI: When the Vim window is partly above or below the
        screen, scrolling causes display errors when the taskbar is not on
        that side.
Solution:   Use the SW_INVALIDATE flag when the Vim window is partly below or
        above the screen.
Files:        src/gui_w48.c

Patch 6.3.074
Problem:    When mswin.vim is used and 'insertmode' is set, typing text in
        Select mode and then using CTRL-V results in <SNR>99_Pastegi.
        (Georg Dahn)
Solution:   When restart_edit is set use "d" instead of "c" to remove the
        selected text to avoid calling edit() twice.
Files:        src/normal.c

Patch 6.3.075
Problem:    After unloading another buffer, syntax highlighting in the current
        buffer may be wrong when it uses "containedin". (Eric Arnold)
Solution:   Use "buf" intead of "curbuf" in syntax_clear().
Files:        src/syntax.c

Patch 6.3.076
Problem:    Crash when using cscope and there is a parse error (e.g., line too
        long). (Alexey I. Froloff)
Solution:   Pass the actual number of matches to cs_manage_matches() and
        correctly handle the error situation.
Files:        src/if_cscope.c

Patch 6.3.077 (extra)
Problem:    VMS: First character input after ESC was not recognized.
Solution:   Added TRM$M_TM_TIMED in vms_read().  (Zoltan Arpadffy)
Files:        src/os_vms.c

Patch 6.3.078 (extra, after 6.3.077)
Problem:    VMS: Performance issue after patch 6.3.077
Solution:   Add a timeout in the itemlist.  (Zoltan Arpadffy)
Files:        src/os_vms.c

Patch 6.3.079
Problem:    Crash when executing a command in the command line window while
        syntax highlighting is enabled. (Pero Brbora)
Solution:   Don't use a pointer to a buffer that has been deleted.
Files:        src/syntax.c

Patch 6.3.080 (extra)
Problem:    Win32: With 'encoding' set to utf-8 while the current codepage is
        Chinese editing a file with some specific characters in the name
        fails.
Solution:   Use _wfullpath() instead of _fullpath() when necessary.
Files:        src/os_mswin.c

Patch 6.3.081
Problem:    Unix: glob() may execute a shell command when it's not wanted.
        (Georgi Guninski)
Solution:   Verify the sandbox flag is not set.
Files:        src/os_unix.c

Patch 6.3.082 (after 6.3.081)
Problem:    Unix: expand() may execute a shell command when it's not wanted.
        (Georgi Guninski)
Solution:   A more generic solution than 6.3.081.
Files:        src/os_unix.c

Patch 6.3.083
Problem:    VMS: The vt320 termcap entry is incomplete.
Solution:   Add missing function keys.  (Zoltan Arpadffy)
Files:        src/term.c

Patch 6.3.084 (extra)
Problem:    Cygwin: compiling with DEBUG doesn't work.  Perl path was ignored.
        Failure when $(OUTDIR) already exists.  "po" makefile is missing.
Solution:   Use changes tested in Vim 7. (Tony Mechelynck)
Files:        src/Make_cyg.mak, src/po/Make_cyg.mak

Patch 6.3.085
Problem:    Crash in syntax highlighting code. (Marc Espie)
Solution:   Prevent current_col going past the end of the line.
Files:        src/syntax.c

Patch 6.3.086 (extra)
Problem:    Can't produce message translation file with msgfmt that checks
        printf strings.
Solution:   Fix the Russian translation.
Files:        src/po/ru.po, src/po/ru.cp1251.po

Patch 6.3.087
Problem:    MS-DOS: Crash. (Jason Hood)
Solution:   Don't call fname_case() with a NULL pointer.
Files:        src/ex_cmds.c

Patch 6.3.088
Problem:    Editing ".in" causes error E218. (Stefan Karlsson)
Solution:   Require some characters before ".in".  Same for ".orig" and others.
Files:        runtime/filetype.vim

Patch 6.3.089
Problem:    A session file doesn't work when created while the current
        directory contains a space or the directory of the session files
        contains a space. (Paolo Giarrusso)
Solution:   Escape spaces with a backslash.
Files:        src/ex_docmd.c

Patch 6.3.090
Problem:    A very big value for 'columns' or 'lines' may cause a crash.
Solution:   Limit the values to 10000 and 1000.
Files:        src/option.c

Patch 6.4a.001
Problem:    The Unix Makefile contained too many dependencies and a few
        uncommented lines.
Solution:   Run "make depend" with manual changes to avoid a gcc
        incompatibility.  Comment a few lines.
Files:        src/Makefile

Patch 6.4b.001
Problem:    Vim reports "Vim 6.4a" in the ":version" output.
Solution:   Change "a" to "b". (Tony Mechelynck)
Files:        src/version.h

Patch 6.4b.002
Problem:    In Insert mode, pasting a multi-byte character after the end of
        the line leaves the cursor just before that character.
Solution:   Make sure "gP" leaves the cursor in the right place when
        'virtualedit' is set.
Files:        src/ops.c

Patch 6.4b.003 (after 6.4b.002)
Problem:    The problem still exists when 'encoding' is set to "cp936".
Solution:   Fix the problem in getvvcol(), compute the coladd field correctly.
Files:        src/charset.c, src/ops.c

Patch 6.4b.004
Problem:    Selecting a {} block with "viB" includes the '}' when there is an
        empty line before it.
Solution:   Don't advance the cursor to include a line break when it's already
        at the line break.
Files:        src/search.c
----------------------

One of the new features (0)

Anonymous Coward | more than 8 years ago | (#13807389)

listed in the CHANGELOG, the bug where children in Nairobi in starving has been fixed. So, there's no more hunger or starvation there. GO TEAM VIM!!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>