Vim 6.4 Released 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.
Why are we hiding from the police, daddy? (Score:5, Funny)
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? (Score:3, Informative)
Regards,
Steve
Re:Why are we hiding from the police, daddy? (Score:5, Funny)
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
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? (Score:5, Insightful)
And in reply to the troll before you:
vim does have mouse support (:set mouse=a) in both terminal and, obviously, gui modes.
Also,
Re:Why are we hiding from the police, daddy? (Score:5, Insightful)
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? (Score:3, Interesting)
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? (Score:3, Informative)
Re:Why are we hiding from the police, daddy? (Score:3, Insightful)
Re:Why are we hiding from the police, daddy? (Score:3, Funny)
Re: Vi Modes Considered Harmful (Score:3, Interesting)
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 t
Re:Why are we hiding from the police, daddy? (Score:3, Interesting)
Re:Why are we hiding from the police, daddy? (Score:3, Interesting)
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 b
Re:Why are we hiding from the police, daddy? (Score:5, Interesting)
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
Re:Why are we hiding from the police, daddy? (Score:5, Insightful)
Re:Why are we hiding from the police, daddy? (Score:3, Interesting)
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
Re:Why are we hiding from the police, daddy? (Score:5, Informative)
Re:Why are we hiding from the police, daddy? (Score:5, Insightful)
Seriously, go read this section: http://tinyurl.com/9qukb [tinyurl.com]
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? (Score:3, Insightful)
> 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 hot
Re:Why are we hiding from the police, daddy? (Score:3, Interesting)
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 "po
Re:Why are we hiding from the police, daddy? (Score:3, Interesting)
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 :
Re:Why are we hiding from the police, daddy? (Score:3)
Vim's not easy to use?
I beg to differ: Cream for Vim [sf.net].
I just want to say thanks. (Score:5, Insightful)
Re:I just want to say thanks. (Score:2)
They deserve a huge pat on the back.
Re:I just want to say thanks. (Score:5, Informative)
http://iccf-holland.org/index.html [iccf-holland.org]
Re:I just want to say thanks. (Score:5, Informative)
Re:I just want to say thanks. (Score:3, Informative)
Bugggg fix only. nice (Score:3, Funny)
That's not surprising. (Score:3, Insightful)
Re:Bugggg fix only. nice (Score:5, Informative)
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.
Re:Bugggg fix only. nice (Score:3, Insightful)
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.
Might have taken a while.... (Score:2, Funny)
Re:Might have taken a while.... (Score:2)
That is because none of their stuff HAS bugs, just undocumented features.
Intellisense #1 feature, pay Bram to add it (Score:5, Interesting)
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. (Score:2)
At least it's possible that it would not be enabled by default.
Re:Intellisense #1 feature, pay Bram to add it (Score:5, Informative)
Re:Intellisense #1 feature, pay Bram to add it (Score:2)
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
Re:Intellisense #1 feature, pay Bram to add it (Score:5, Insightful)
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: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 (Score:3)
Re:Intellisense #1 feature, pay Bram to add it (Score:5, Insightful)
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 (Score:3, Insightful)
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.
Also, write code that can be understood. (Score:3, Insightful)
hats off to Bram, Bill Joy, and ATT (Score:5, Interesting)
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... (Score:5, Interesting)
Re:Not only is it a fantastic editor... (Score:2)
Re:Not only is it a fantastic editor... (Score:2)
Re:Not only is it a fantastic editor... (Score:5, Funny)
Re:hats off to Bram, Bill Joy, and ATT (Score:2)
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 arbitrar
Re:hats off to Bram, Bill Joy, and ATT (Score:2)
with a perl script. written on vim of course!!
Re:hats off to Bram, Bill Joy, and ATT (Score:3, Informative)
You mean something like this ?
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
Re:hats off to Bram, Bill Joy, and ATT (Score:2)
Check my exemple a few posts below, even tho I do use "g" there.
The most simple command for this would be:
I also like to use @ instead of
Re:hats off to Bram, Bill Joy, and ATT (Score:5, Interesting)
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 (Score:2)
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 r
Re:hats off to Bram, Bill Joy, and ATT (Score:5, Funny)
Way to ruin it buddy.
Bug fixes (Score:5, Funny)
Re:Bug fixes (Score:2)
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 (Score:2, Interesting)
Re:Bug fixes (Score:3, Informative)
I for one... (Score:5, Funny)
(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! (Score:5, Funny)
Did someone mention the Fantastic Four? (Score:5, Funny)
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 (Score:5, Interesting)
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 (Score:4, Informative)
How do you do a character literal? (Score:5, Interesting)
Re:How do you do a character literal? (Score:3, Informative)
Re:How do you do a character literal? (Score:2)
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? (Score:2)
If what I just did in gvim is any indication, ^V works just peachy in Vim.
I thought Vim was a finished project (Score:2, Insightful)
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? (Score:2, Funny)
Yipee! (Score:4, Interesting)
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! (Score:3, Funny)
Re:Yipee! (Score:3, Interesting)
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 ru
Re:Yipee! (Score:4, Funny)
I bet you're loads of fun at parties!
Need release faster (Score:5, Funny)
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 (Score:5, Funny)
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...
Vim can't do exorcisms... (Score:3, Funny)
:help the damned
~
E149: Sorry, no help for the damned 0,0-1 All
:-(
If you're a loyal Vim user... (Score:5, Informative)
Maybe it is not interesting... (Score:4, Insightful)
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 (Score:3, Informative)
----------------
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
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
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
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
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
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ë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
----------------------
emacs and vim are too difficult to use (Score:3, Interesting)
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 [nedit.org]. 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 (Score:5, Insightful)
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 source code (Score:5, Funny)
Last Of The Well Behaved Editors (Score:5, Interesting)
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:
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 (Score:3, Insightful)
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 a
Re:A Year? (Score:2, Insightful)
Re:A Year? (Score:2)
Re:A Year? (Score:3, Interesting)
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.
Re:Yes, but is it better than emacs?? (Score:3)
Re:Yes, but is it better than emacs?? (Score:3, Funny)
Re:Yes, but is it better than emacs?? (Score:2)
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?? (Score:2)
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, ther
Re:Yes, but is it better than emacs?? (Score:2, Funny)
Re:Yes, but is it better than emacs?? (Score:2)
and everyone else uses Vim.
Re:Yes, but is it better than emacs?? (Score:5, Insightful)
Uhm, because some of us like modal editors?
Re:Yes, but is it better than emacs?? (Score:2)
Re:Yes, but is it better than emacs?? (Score:2)
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?? (Score:2)
"I have hacked Emacs with vim."
Heh, I had a giggle this morning when I checked my history file and found:
8^)
Re:Yes, but is it better than emacs?? (Score:2)
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?? (Score:2)
Re:A vim library? (Score:3, Interesting)
we have a core library that manages the whole 'editing' aspect, syntax highlight, plugins, language bindings, configuration
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
Re:From a newer Linux user's POV (Score:3)
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