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.
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.)
... 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.
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
Hm, for some reason notepad doesn't work from ssh. With commands like cl, cw and so on. VIM makes the perfect editor for quick edits on a remote computer.
Understanding is a three-edged sword. -- Kosh Naranek
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.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Neither of these two editors works like the sort of editor which people are exposed to these days. Why do you have to have an insert mode? This "feature" came from vi but for me it is exactly like bolting primitive editing behaviors on to more or less
In my day job as a senior programmer I introduce new staff to nedit. I also tell them to make their own choices about the tools they use. Most continue to use nedit because it has a few simple features which enhance usability. For example each function has a menu item, and each menu item tells you which key to use as an alternate way to reach the function. You don't have to worry about which mode it is in. Simple standard actions like opening and closing a file work in exactly the same way as other editors like gedit.
So for me people use vi(m) and emacs out of habit. Unless these tools improve they have no serious future in competition with eclipse, etc. Neither does nedit, for that matter but it will at least provide a better option for people new to *nix.
http://michaelsmith.id.au
Nothing is wrong with those, however generally speaking, they aren't installed by default on a unix box, while vi/vim/elvis or some other vi-type editor is installed on pretty much 100% of every unix box I've been on, from linux to solaris to *bsd to hpux. Personally I love vi, however I understand it's not for everyone.
Everyone who works with unix should learn how to use vi though, for the simple reason that it's on pretty much every unix box out there, and is the editor you're pretty much guarenteed to be able to have available if $random_person asks you to quick jump on their $unix_box to [do something].
I disagree that everyone should learn to use vi. It's not a cost-effective investement in my opinion (nor is emacs, although there are some modes that might have changed my mind if I was heavily into the things they deal with). You spend months typing like a turtle. By the time you actually get up to a reasonable speed, you have used so many seconds, minutes and hours that you'd need some truly impressive productivity gains to make it worth it.
;-), it's not really worth it to switch to a post-PARC editor. Not if you're already up to speed. While skills in regular modern text editors are useful because they are transferable, they are quick to learn anyway, that's what's nice about them.
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
xkcd is not in the sudoers file. This incident will be reported.
I know the geek community generally swears by vim and emacs, but to newer users they're both a closed book. Any search for understanding and explanation is met by what appears to be insanely complex reasoning..
These are text editors, right? Or what? What is their purpose?
Why are they so complicated to use?
I mean, I would have thought the more advanced features would be complicated. But plain vanilla text-editing..? It seems you need to press obscure commands just to be able to scroll through a file, let alone edit it.
I think it's things like this that puts many newer Linux users off configuring things themselves, as having to deal with programs such as vim and emacs is more than a little daunting.
yes. http://www.yzis.org/
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?
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
Between * to automatically search, bookmarks, the ability to replace several words or letters without having to select them, and ctrl-p/n (tab in my vimrc) to autocomplete words, vim is vastly more effective than traditional editors. I can't stress enough how switching back to editors that use a mouse and keyboard together slows people down. With vim (not mere vi, that sucks too), I keep my hands where I need them to type, it saves me minutes if not an hour every day. And autocomplete minimizes typos speeding up debug time.
I've been using vi editors fo ages for the simple reason that nothing else was available. Well, I wouldn't have used Notepad (I don't think I've ever used notepad) but something with a more modern interface would certainly have been welcome. And if you don't like vi, go play with the system editor on VMS, it's not much better.
The purpose of vim isn't to make a user friendly editor, it's to make a better vi. vi isn't a user friendly editor, it's a horrible relic from another age which however happens to be :
1. Quite powerful
2. available on pretty much any Unix machine
3. therefore well known by most Unix users
When I came upon machines that could run Emacs I usually ran that because I found that it was more comfortable for me, however I just used what was available, so learning vi and Emacs was just what everybody did. You were free to prefer whichever.
However the main advantage of vi over Emacs is that vi (the original) is much more lightweight and can typically be used when the system is slightly broken (having a statically linked vi is always a good idea). I'm not sure that's still true with vim.
I still tend to point out vi to beginning Unix users (the tinkering kind, not the office desktop users) mentioning that for historical reasons (many things on Unix are there for historical reasons), vi is the default editor on most systems and you can usually rely on it being present. So learning a subset of commands (insert, delete, replace, save, quit without saving) is always a good idea.
On a side note, when I installed Gentoo on the machine I'm typing this on, the installation manual said I had to edit a few files. Except there were no editors installed. Or at least no vi. No vim either. No vi*.
It took me a good 15 minutes to figure out that a thing called "nano" (of which I had never heard) was installed by default to be used as an editor while vi was optional. This is a typical braindead decision. Adding a user friendly editor is always good, removing the widely acceptly default editor (quirky as it is) is always bad.
May contain traces of nut.
Made from the freshest electrons.
My experience was even faster than that. The number of basic commands I needed to learn was very small, and after using vi-like programs for years now, I still have barely scratched the surface. I never did quite get the hang of using hjkl for movement, but that is seldom an issue these days. I'm currently working on using the native cut and paste commands instead of the mouse and menu.
Way back when, vi was the only text editor on a class of systems I needed to work on, and I figured that if I used it for everything I wouldn't need to constantly change my mode of thinking when switching from system to system. I was pleasantly surprised to learn that gvim for windows combined vi semantics with all of the windows editor semantics that I was used to. (My previous text editor was PFE.)
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?
(If you want to compare the two, type "ed <some file>" at the command prompt on most *IX systems (including cygwin under MS-Windows), and try to edit the file.
Vi(m) is so much better.)
Even when editing on a DECWriter (a hard-copy terminal popular back in ancient times), I preferred using ex, the one-dimensional version of vi, to using ed.
Vi has held up surprisingly well over the last couple of decades, and (g)vim's added capabilities have made it even better.
(I really like the '*' and '#' commands, and being able to use the mouse and arrow keys in insert mode.
Oh, split-screen mode.
Etc., etc.)
Vi has done a decent job making the transition from TTY to GUI.
The one thing that annoys me sometimes is when I accidentally try to use vi commands in a non-vi setting.
For example, more than once I have accidentally dismissed a dialog box after filling in a text box because I hit the escape key to terminate insert mode.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
The conclusion most will draw from your argument rests on a faulty implication: that vi was intended to be more featureful than Notepad.
If Bill Joy had had access to the screen capabilities of a graphics engine, instead of a glass-TTY, there might never have been a Notepad, because vi would have had a mouse and a cursor and still would have had need to put all of vi's "power" into the editor he chose to write.
Vi isn't as "easy to use" as Notepad because Bill Joy lacked the technology. Notepad isn't as "powerful" as vi because Microsoft lacked the concern.
None of this stopped Richard Stallman, who put everything into emacs. But then, nothing stopped Richard Stallman, who put way too much into emacs, and suggested the problem was that you lacked two extra fingers and an eidetic memory for command strings and an understanding of the obvious need for operating-system internals in a text editor...