Slashdot Mirror
Vim 6.4 Released
file cabinet writes to tell us that for the first time in more than a year Vim has released a new version. Version 6.4 stable was released yesterday and while there are no new features added they are touting dozens of bug fixes.
In good sadness, though, I'm looking forward to the spell-checking in Vim 7.
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.
Cyric Zndovzny at your service.
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.
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
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.)
I hope they fixed the bug that made you type all those weird key combinations to write to a file and save.
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?
there's more than one way to do me.
...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.
"And then I visited Wikipedia
The last version of Emacs came complete with Vim v. 10.03c! ;)
... 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.
Cyric Zndovzny at your service.
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.
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.
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
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.
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.
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.
Best Buy can have you arrested
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 *
... don't forget that it's charityware.
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?
user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
The change log;
.gvimrc you may only get one line for the cmdline. (Christian Robinson) Invoke command_height() after the GUI has started up.
/path" to "-isystem /path" for "make depend".
----------------
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. Al
{{.sig}}
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.
So.. it has come to this
that's exactly what we are doing with Yzis ;) .... , and GUIs 'clients' that just sends inputs and displays outputs.
:)
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 on the way and should be avail quite soon.
we are growing slowly but we should be able to release a stable initial release within a year.
any help is welcome
Mik, Yzis developer
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?