Slashdot Mirror
Vi IMproved -- Vim
Learning to crawl
Books describing editors generally fall into two categories. The first category of books will describe a particular function (like moving through a file) with all the known ways for performing that function, ad nauseum. The second category distills the myriad of ways to perform that function into a handful of the most common or most useful ways. Vi IMproved -- Vim combines both methods with good results.
The first section of the book is entitled Basic Editing; this section introduces the reader to starting and using Vim effectively without getting too bogged down in the gory details of Vim's vi heritage. In the chapter on moving around, the author begins with two methods of movement. In the details portion, the author has the reader performing more complex movements. This is a good approach, much like learning how to walk before learning how to hop, skip, jump, and dance through your document. Unfortunately this approach makes using this book as a reference very difficult. I would read sections that I wanted to use later, only to realize I couldn't find the section again. Vi IMproved -- Vim more than makes up for this shortcoming with a generous appendix detailing the Normal Mode, Command Mode, and Visual Mode commands along with a well-designed quick-reference section.
Made to Order
One of the strengths of Vim over other vi clones is Vim's ability to be used as a regular GUI application, and not just as an xterm-enhanced application.
Vi -- IMproved Vim shows not only how to use the GUI, but also how to customize the GUI to fit the reader's preferences. A good portion of this book deals with customizing Vim to suit the reader's style through the various parameters, menus, and GUI elements. Users who like their editors as stock as possible will find themselves skipping a lot of pages in this book. However even they will be tempted to try out some of the neat functions that pop up as they flip through the pages. The author conveys a sense of exploration, inviting users to experiment and try out new things with Vim.
Errata
Unfortunately, with vi and its clones, a single letter can mean the difference between moving through the document and deleting half of it by accident. Vi IMproved -- Vim is plagued with typos and errors, making this a difficult book for newbies to get into without having the errata sheet from http://vim.sf.net handy. It's understandable why a book like this would have some errors, especially with vi and Vim's terse keyboard commands.
Conclusion
Users of Vim will no doubt be thrilled with Vi IMproved -- Vim. Having a reference outside of the help menus in the program is a godsend for any user of Vim. Unfortunately the errors in this book mar what could have been the definitive book for Vim users, but for those who are starting out with Vim, or who would like to know more about Vim, this book is the perfect starting point and reference. The book covers the 5.x series of editors, but that shouldn't be a problem for most people looking to get started with the 6.x series.
If you're using Vim, you need Vi IMproved -- Vim.
You can purchase Vi IMproved from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Next: ls for dummies
[mandatory troll about how EMACS 0wnz Vi/Vim here] :)
--pi
Finally!
Something that I can use that's better than ed!!
(sorry, it was that or some emacs crack)
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Vi Improved
As opposed to those people who are too dumb to use proper grammar.
It's hard to take seriously a text editor named after a sink cleaning product.
Vim
-----
You get spoiled by it's features.
I use Vim on my Debian box at home, but I am stuck with standard vi on the Solaris boxes at work.
I really miss some of its features when I'm "stuck" with "vanilla" vi.
I'm afraid if I get this book I'll miss it even more.
Heffel
Expert Java EE Consulting
"Enron Biotech has discovered a gene which may explain the sharply divided preference in the hacker community between Vi and Emacs," said George Stefanscamoulus . "this may help us to utimately produce the perfect hacker". "Only we still haven't figured out which program is really the best. More R&D is needed."
[mandatory flaming response about how Vi/Vim 0wnz EMACS here] :)
--pi
A book written to guide the newbie through a prickley (powerful!!) editor and it's chock full of errors?? The whole point of purchasing on of these is to provide a leg up the learning curve.
Sorry, no sale.
(The authour probably uses emacs, or worse, Word.)
"Remember, any tool can be the right tool." -- Red Green
The errata sheet can actually be found here. The link in the story was only Vim's home page.
Rich
What does it provide that the Vim HOWTO doesn't? This strikes me as useful as a 'Developers Guide to ctags'.
~~ What's stopping you?
Although I am a die-hard emacs freek, on occasion I use one of those spiffy one-handed chording "keyboards", and I must say, vi *rocks* in that case.
Okay, that's all. Get back to your cubicles and your Nerf(tm) Mortar Launchers.
... ora's "learning the vi editor"? it has almost 40 pages on vim, and is (as usual with ora) a very good book.
Listen most programmers I know use emacs and love it. They love the features and they are use to the interface. fine.
_ _
Yet, I am a sysadmin at heart and when it comes to editing things on the fly. vi is everywhere. It does not matter what way-old silly box sitting in the corner that I find vi is there. Sometimes I get stuck on windows box for a second and find myself hitting the ESC key. HA!
I do not why things have to always have to be so heated. If you know and like emacs use it otherwise set EDITOR=vi and be done with it.
People use different tools for different tasks sometimes because one is better than the other. Sometimes it is a just a matter of personal choice. Why this is so hard to understand is beyond me.
_______________________________________________
ACK
I think most people will find all the VI they need to know on the Vi reference card at vh224401.truman.edu
The obvious answer to that R&D is to ask Gene Hackman which he prefers.
He'll probably blow us all away and say something completely out of line. Like, "pico".
-Riskable
"Those who choose proprietary software will pay for their decision!"
his suggestion? mg - it's apparently "like emacs" except "without the bloat".
2 1337 4 u!
and while you're at it:
M-x repl-str 'people are' 'people who are'
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
With vi in command mode almost all the keys around bound a screen movement, or editing command. I can jump around an entire file, search/replace and do any number of complex and repeditive editing operations without taking my hands off the keyboard. In many cases I dont even have to take my hands off the homerow.
Vi is a powerful, small (memory), and fast editor thats available on every unix system I have ever seen.
The End.
El riesgo vive siempre!
Funny, I still don't use "info" pages and the emacs help system because there's no obvious way to navigate the system. I'm not sure why they both don't just use "less" and be done with it. :)
Vim does indeed rock. If you're a coder and like vim, check out
vim.sourceforge.net
Tons of plugins/tips....vi is not just for sysadmins anymore.
Unfortunatley, according to the linked website, the book only covers up to version 5.7. That means you miss out on some useful features like code folding, some screen splitting, etc.
--You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
This is the worst book. I was a VIM newbie coming from Windowz land and the book did more to hurt me than help. It is very poorly written and has so many errors that you can't trust it. Even if the errors were fixed in a second version it'd still suck. The organization of the book is just afwul, I'd hate to see code the author generates if this spagattii is what he writes. Ick. Save your cash. Look at the customer reviews at Amazon.Com, there are quite a few "excellent" reviews, but more telling are the rare awful reviews:
... perhaps I can get a refund? Any other suggestions?
.* unless you anticipate that there would be more than one comma on a line, in which case, any command would fail. :substitute command. Take a breath Mr. Oualline, and teach the basics first.
:-) BIG raspberries to New Riders for letting this slip through without proper editing. And thanks to Bram, who put up an unofficial list of errata at www.vim.org.
*____ Disorgainzed, Haphazard explanations -- refund time, April 8, 2002
Reviewer: Cameron from Washinton, DC
This book is poorly structured, for example, as a newbie I tried to figure out how I could insert a file into my current buffer... simple operation, yet with this book it took me 20 minutes before I literally stumbled accross the appropriate place in the book. This book is not organized well and it hurts. Further, the author doesn't explain VI concepts well at all. The reference part is just as dis-oraganized as the rest... just try to find what you are looking for. What made me write this review is that I just wasted another 10 minutes looking for how I can have two buffers open (but not two windows) Anyway, I've given up on this book
*____ Too confusing and too many errors, May 19, 2001
Reviewer: James Snyder from Mt. Holly, NJ United States
So far I have only read up to page 118. The large number of errors I have found so far is mind-numbing. I pity the poor beginner who has to plow through these mistakes in order to try to understand the vim program. For those who already have a copy, I ask you to compare figures 2.4 and 2.5 and tell me what is the difference between the two sets of arrows. Look at figure 2.13 and find the two outright errors, the inconsistency, and the point that might be confusing to a beginner. Read the section entitled 'How to Change Last, First to First, Last' on pages 103 and 104 and find the following:
1. The \(, \), \1, and \2 used here will not be introduced until page 213.
2. The regular expression in figure 9.2 is labeled a 'command', while the command itself is found nowhere.
3. The dollar sign in the regular expression is redundant.
4. The [^,]* could be replaced with the simpler
5. The space after the comma in the names file is not properly accounted for.
6. Who changes last, first to first, last anyway? It should be changed to first last, with no comma.
This nonsense appears just after the author has introduced the
These are not isolated problems, the whole book is like this.
My opinion is that:
1. Mr. Oualline has too much experience with vim to remember the needs of a beginner.
2. The artist who created the figures seems to have no experience with vim whatever.
3. The review process at New Riders is too careless.
***__ Does anyone actually read the books they review???, July 23, 2001
Reviewer: David F DelGreco (see more about me) from Fremont, CA USA
I decided to learn Vim because I work on WinNT/2K, Linux, and Macintosh boxes. Using a single editor makes it easier to work on mulitple platforms.
My review of this book is mixed. First, it's the only book on Vim and it contains a lot of information, so that's a plus. Also, it shed a lot of light on using the editor that, frankly, the help files did not (you can look up *ANYTHING* via ":help ", but the documentation is not very accessible to the new user). However, the typos, errors, bad grammar, and personal idiosyncracies of Mr. Oualline just have to be seen to be believed.
You can figure out most of the errors easily enough. For example, there's a reference to the non-BUI version of Vim (I think he meant GUI)and for some reason, in the word "filename", when used as an example (e.g., "type 'vim filename'"), the "fi" is sans-serif while the rest of the example text is in bold Courier. There are, however, numerous places where the diagrams don't match the example being discussed in the text or are just plain wrong. Some of these left me wondering if I had missed something, but trying out a command in Vim quickly showed the diagram was wrong. My favorite goof is where '#' (the command to search backwards for the word under the cursor) is shown in numerous places in Appendix C (pp. 445, 449, and elsewhere) as a British money sign (e.g., "/count/ L"), where L is the pound sign. Get it? Pound sign? Obviously the person who did the Appendices and Index (and copy-editing???) was not Mr. Oualline.
With regard to the content, I found that Mr. Oualline is very idiosyncratic. Vim is VERY flexible, using ancient Vi ways of doing things, as well as more modern ways that are easier to use. Take yanking (copying) a block of text to a register (like the clipboard). *Mouse way*: select lines, press y. *Visual way*: move cursor to top of lines to be selected, press V, select lines, press y. *Vi-ish way*: go to top of lines to be selected, press "ma" to drop a mark labeled "a", go to bottom of lines, type y'a (yank from current position to mark "a").
If you consider these different styles (mouse, visual, or Vi-ish) to approaching the same general problem, Mr. Oualline always goes with the Vi-ish style, to the point of also showing you in many cases how to precede the command with a line range instead of using marks. Where Ctrl-Wn (open a new window) will do, we get Ctrl-W Ctrl-N (equivalent). Where Ctrl-W moves down one window, we get Ctrl-W Ctrl-J (the arrows aren't mentioned). My guess is that this is not how the majority of new users will use Vim (though it might be handy if you find yourself using Vi or Vim via telnet).
A real barrier to learning the editor is the immense number of variations for accomplishing a given task. Multiple keystrokes to accomplish the same thing, as well as different approaches. What would be great for Vim is an attempt to break down tasks into functional groupings (movement, formatting, programmer stuff, managing buffers/windows) and choose a style (probably visual mode, which is almost interchangeable with mouseing) so you can say "here's a good way to get started." The many variations can be left as an excercise for power users. They are available in the online help, anyway.
All in all, I learned a lot about Vim from this book. But if I hadn't been determined to do so, I would have given up. If you want to learn Vim and the online docs aren't doing it for you, buy this book. You've been warned, so just chuckle when you come across errors and general weirdness. Kudos to Mr. Oualline for writing a book, but don't give up your day job.
For those on a budget (or cheap) New Riders has released the book here
UNIX/Linux Consulting
At work, having to deal with code without a decent editing environment (like SQLServer stored procedures editing) I missed vi but solved the problem with a free tool: winvi.
http://www.winvi.de
-=-=-=-
-=-=-=-
Oh, and here's another advocacy gem from Usenet:
-=-=-=-
Since I'm still fighting to get my lines long enough to satisfy the lameness filter, I might as well throw in another this old joke while I'm at it.
(Attribution at the bottom of the post)
/bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
When I log into my Xenix system with my 110 baud teletype, both vi *and* Emacs are just too damn slow. They print useless messages like, 'C-h for help' and '"foo" File is read only'. So I use the editor that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME ed - text editor
SYNOPSIS ed [ - ] [ -x ] [ name ] DESCRIPTION Ed is the standard text editor. -----
Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929
Of course, on the system *I* administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ?
--- Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
--
From: patl@athena.mit.edu (Patrick J. LoPresti)
Message-ID:
Sender: news@athena.mit.edu (News system)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Newsgroups: alt.religion.emacs,alt.slack
Organization: Massachusetts Institute of Technology
Lines: 95
Tales from behind the Lagom Curtain
No, dog is God spelled backwards with the all characters lowercased.
God was here first.
There are only two kinds of people who don't like 'vi':
1) Those who can't type
2) Those who don't understand 'vi'
Yes, Emacs has a programming language that theoretically gives you some advantages, but you can't beat the power of 'vi' for being able to do complex edits extremely quickly (without having to write a program).
Sometimes it's best to just let stupid people be stupid.
Well, there are enough little changes between 5 and 6 that doing anything beyond "looking to get started" is a pain. Why write a review of a book that's been out for some time now, and is due for an updated edition?
Java is the blue pill
Choose the red pill
Of all the things geeks fight about, it's always the text editor that draws the most blood. For an outsider it must sound rather petty. ;)
I've found vim to have extensive documentation, though sometimes, just finding the right information is incredibly difficult to do. (I just end up grep -r ing the documentation dirs)
If you're starting out, a cheaper hard copy alternative just to get you started (since one of the major roadblocks is the initial learning curve) is the vi quick reference from O'Reilly. Nice too that it points out vanilla commands vs implementation specific ones. Information is nicely arranged too. I think I've even seen printable posters with beautifully arranged command maps.
Myself, I only use the basic commands anyways, I don't need the full set of features. I work on so many systems that customization is not an option. And sometimes, all these extra options just get in the way. Magic indents are interesting, ability to execute perl is interesting, but I don't really need them, infact I find them annoying. (I end up undoing the formating that vim magically formats for me) For my personnal system, I usually end up remove all the xyzzy and stick with the basics.
This book looks like a good step forward (at least I can search a pdf in one shot!) but it starts out telling me lots I already know how to do because it's just vi, not the improved part. Where's the single doc "here's what we improved"?
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
I hate vi (too weird) and emacs (weird, and bloated). Well, I should say I made a run at emacs once but never bought into the lifestyle so it was just too much overhead for simple edits.
I've instead been a longtime fan of joe. Simple, lightweight and powerful enough for more complicated jobs. AND it's user friendly.
On slashdot, you haven't done anything until you've gotten at least one +5, Troll.
...is that it has the worst index of any book I've bought in recent years. With this index, quickly searching for information is almost impossible unless you're searching for info that's fairly obvious to any vi user. Because of this, the book is probably a decent tutorial but it sucks as a reference.
Much better references can be found in the ViM help documents. In fact, the documentation is better from the included help IMHO; the problem is navigating the help files is about as intuitive as using info (which I think is about the least intuitive document navigation system ever produced).
I have learned a lot about ViM from browsing the book, though, so I can't totally trash the book. I just think there's lots of room for improvement.
EMACS 0WNZ VI (Score:1, Flamebait)
by The Pi-Guy (wiseguy586@@@yahoo...com)
NO, VI 0WNZ EMACS (Score:1, Funny)
by The Pi-Guy (wiseguy586@@@yahoo...com)
Only on slashdot ...
Y
p (or P)
You can do the same thing with buffers if you wish to write several discrete sections to another file.
Give a man a fish and he will eat for a day.
Teach him to eat and he will fish forever.
Vim also can embed a Python interpreter (and perl too.. but... ). I have spent a little time setting up Vim to be the centerpiece of a Python IDE. If anyone is interested in my stuff send me an email. Perhaps we can exploit the built-in Python even further to make it even better. Who knows... perhaps a Python-zippy for Vim is just around the corner...
--
The early bird catches the worm. The worm that sleeps late lives to see another day.
How do I mark a section of text (say lines 20->25) and then automatically indent them 5 tab spaces (or maybe take a tab space out of the beginning)?
Bryan
You may be looking for :20,25>>>>> . Or if you don't know the exact line numbers, move to the last line, mark it 'a' with ma, move to the first line, and then :.,'a>>>>> . This will move the lines over by five times the "shiftwidth". (How many columns this is and whether you get tabs or spaces depends upon, among other things, the shiftwidth, tabsize, expandtabs and smarttabs settings.)
Esli epei etot cumprenan, shris soa Sfaha.
Another wonderfully useful feature of VIM is that you can record useful, exacting macros with VIM, which you certainly can't do with MSVC or, in my relatively limited experiece, any other editor other than emacs. All the power of VIM's normal mode is present in its macro capability.
Another bonus of VIM is that it can simultaneously display many different files split horizontally or vertically. While MSVC will allow you to do this, the title bars and scroll bars in all of those windows eat up so much screen space that it's not worth doing for more than two files.
Also, the syntax highlighting in VIM is better, or at least more configurable. For example, I've been using doxygen lately. I really like the different elements of a doxygen comment to show up in different colors so that I can pick out easily when I've made a stupid mistake. For VIM, I just went to vim.sf.net, found the friendly doxygen.vim syntax highlighting fixeruper that someone had written and I was in business. With MSVC you could probably write some extension to highlight the syntax the way you wanted, but what a pain.
In the end it comes down to using a tool that is designed for the task. VIM was designed for editing code. The MSVC editor employs the same basic editing philosophy as notepad or MS Word, which were certainly never designed for coding. Just a simple example: VIM has a set of commands which work in a line oriented way. Software is written in lines. Honestly, a good deal of what I find myself doing with code is moving a line or a group of lines around.
Before I starting using VIM, I was the most efficient person I knew at editing code in MSVC because I had the keyboard commands down. Now that I use VIM, I really do edit code way faster, especially for any sort of repetitive task.
On our next episode, "A guy's perspective on the new Tampax with wings."
I use both at work, so if anyone knows how to do these vim things in MSVC, let me know.
1) Repeat the last command
2) Execute a command an arbitrary number of times
3) Folding
4) Non-overlapping windows of different files
That's all I can think of right now. I've really tried getting aquainted with MSVC, since it has our project management integrated. But when I need to do non-trivial code changes, using vim always, always is easier.
> Any Text Editor That Needs A Book is hopelessly
> broken.
I truly hate this philosophy of interface design. It's what gives us useless, dumbed-down GUIs and languages like COBOL. Requiring the slightest goddamned effort by the user can make everybody's life easier.
"Whatever happened to fair use?"
-- Duff-Man
I found this VI tutorial particularly easy to follow.
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
Well, it was probably a 7.4962 and the reviewer decided to round up for brevity's sake and in order not to convey a false impression of precision.
Well, I'm CERTAINLY glad to hear that!!!
:-)
So when, exactly, is kdevelop going to appear in base installs of Solaris, AIX, HP-UX, FreeBSD, IRIX, and so on?
And how are we going to magically back-implement them to all of the older platforms that are already installed?
Oh, not to mention make them available for a minimally-running system, being accessed from a remote VT-102?
Oh, silly me--kdevelop and anjuta are IDEs! vi(m) is a text editor, last time I checked. As a text editor, it's still got some life in it.
Emacs, as an editor or an IDE, also isn't quite dead yet. However, it's dying--I don't expect it to hang on for much more than 15 more years.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Ok, rant time. I'm big Vim fan. Every computer I own or use (well, every working computer) has it installed. The only editor that approaches EMACS's feature set, and nowhere near the great bloatware's klunkiness or unpredictability. But.
I'm rather disappointed that EMACS and Vi (and its clones, of which Vim is the best and mostly widely used) remain the most widely used text editors. Now each has strengths and weaknesses relative to the other, and it's no use rehashing those wars here. What's important is that both these editors are designed around constraints that are about 20 years out of date. Most especially, they were designed to be used by a text-mode terminal (very fancy ones, in the case of EMACS, very limited ones in the case of vi) over a relatively slow connection.
I won't comment on EMACS, since I lack the obsessiveness to be a serious user. But on vi, the big design decision was to build in a lot of modes to get around the limitations of the terminal. This allowed a lot of commands without function keys or complicated keystrokes. It also allowed the user to enter blocks of text without realtime update -- an essential feature on a 300 baud connection!
But, in a GUI environment, modes are a Bad Thing. Yeah yeah, some of you like being able to do complicated edits without moving your hands off the keyboard to grab the mouse. But most people have an easier time if they don't have to keep a state map current in their head.
Now Vim has impressive GUI support (platform-independent GUI support, which is the main reason I use it), but it still has all the modes of vi, plus 3 or 4 of its own. And its macro language is a kludgy extension of the simple-minded command language Bill Joy invented for the original ex/vi editor, itself a minor extension of the ed command language.
Various projects have tried to do all this over using modern design principles, but the EMACS and Vi user communities are just too entrenched. If I were a better programmer, I'd try it myself, maybe using the vim engine as a basis. But probably I'd be the only user!
Slashdot has a very nice FAQ section - please read it. You have misunderstood what the score means and have made yourself look a fool in front of thousands. ;)
take lines 20-25 and indent 5 tabs:
20G5>>....
take lines 20-25 and remove one tab:
20G5
hope that's what you were looking for
A buddhist walks up to a hot dog stand and says ``Make me one with everything.''
One trick: some Motif programs (notably Netscape) have bad palette manners and grab a lot of colors they don't even need. I would always have at least one copy of gvim running so it always had the palette colors it needed.
D'oh. That second one should have been
20G5<<
A buddhist walks up to a hot dog stand and says ``Make me one with everything.''
Easy: I can't run the MSVC editor from an SSH session.
The thing is, for the MSVC editor, all the commands are "hidden" in menus you reach with the mouse, and the keyboard shortcuts associated with them. vi just has different shortcuts.
If you don't like vi, just use a different editor. Just use what you like best, like all of us do. I don't like vi, I use joe, jed, pico or emacs. Do I complain that vi sucks? No, because it doesn't. It just doesn't fit the way I do editing.
One shall speak only if what one has to say is more beautiful than silence
Heh. Well I'm a sysadmin and maintenance analyst, which means I get called in to work on an unknown system which is braindamaged. Since they're usually big servers, they almost never have framebuffers, meaning I'm usually stuck with a terminal session, or in a surprising number of cases, a real, honest, hardwired VT-102. (rarely a VT-52, sometimes a VT-420)
:-), and is all I need (I'm not a developer), I can't be bothered with a proper IDE.
vi is always there, and always works. Since it is massively useful, consistent across the Unix universe (more or less
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
> Can you script the MSVC editor?
Uh, select "Macro" from the tools menu.
> Can you set up any key binding you want?
Select "Customize" from the tools menu and click the "Keyboard" tab.
> Can you execute commands arbtitrary numbers of
> times?
I sure wish it could. My boss ribs me for using vim whenever I need to do real work, but the MSVC editor is not as brain-dead as that.
> In the end, you're either a troll or a moron.
No kidding.
"Whatever happened to fair use?"
-- Duff-Man
One thing that annoys me to no end is when I install the latest version and by default some new silly screwball "IMprovement" is activated.
Like the time line numbers (:set nu) have lines under them. You have to turn that off with (hi LineNr term=bold).
In the latest release (from RH actually) they put visual line breaks (not real newlines) in lines that are longer than the terminal is wide so that it doesn't print text in the left margin. Supposed to look nice I guess. Not only is that just a silly worthless feature but now if I select a line in X with the mouse and paste it somewhere I get stairstepping text.
I think their stuggling for new ideas. I wish they would clean up that morass and make a nice X widget instead.
This book is optional. `man vi` is sufficient for most people.
The editor that comes with MSVC is usable without a book.
This is debatable. I used MSVC once and remember not being able to type but a few characters at a time before some lame popup or menu prompted me for mouseclicks or selections. These things are probably customizable (sounds like the MSVC on-line help would get used quite a bit before these wrinkles are ironed out).
vi is faster than MSVC, once you have learned a few command keys and understand regular expressions. vi can be extremely productive. MSVC really caters to the newbies of the programming world, and it can grow old pretty quickly once you want to do things faster.
What can VI/VIM do that it can't?
10yy kkkkkkk p (fast copy and paste, for example)
(The numbers after the colons above define ranges of line numbers to operate upon)
The only real weakness of vi is formatting written paragraphs (Emacs has Meta-Q for automating this).
You may see the obtuseness of VI as part of the initiation; I see it as damage and route around it.
Actually, fans of vi see it as a very efficient tool to get the job done. I have saved much more time using vi than I have spent learning it. This is the reason vi just doesn't go away to be replaced by something "superior".
Healthcare article at Kuro5hin
Ummm...this is silly, but you can't reasonably expect someone to transpose two characters using a mouse?
-- Slashdot: When Public Access TV Says "No"
I first heard it when it was Eight Megabytes, rather than Eighty. (Althought it was past the time when 8MB was considered a huge amount of RAM... I was using SPARCstation 1+s with 12 to 16MB of RAM.)
I hope RMS isn't singing it...
You may see the obtuseness of VI as part of the initiation; I see it as damage and route around it.
This is a common misconception among people who are unfamiliar with vi (that the people who use it know that it's hard to use, but use it anyway because they're stuck and the past and so that they can feel smug and superior to the Common Man who can only use Common Editors.) However, it's dead wrong.
I use vi because it's easy to use. That's right; vi is easy to use.
It is not, however, particularly easy to learn, and here's where the problems arise: too many people confuse ease of use with ease of learning. If you sit somebody down in front of a tool such as the MSVC++ editor, of course they will be able to learn it quicker than they would be able to learn vi, particularly if they are already familiar with concepts such as the mouse, pull-down menus, standard keyboard shortcuts, and other familiar elements of modern windowing environments.
But does that mean that, at the end of the day, the MSVC++ editor is easier to use than vi? I don't think so. For example, if I want to delete 8 lines of text in vi, I simply type "8dd". Now, you might say "Well, all I have to do is take the mouse, highlight those eight lines, and choose Edit->Cut or press Delete or Control-C or Control-X or whatever", and you'd be right. And this may be more intuitive and familiar then pressing "8dd", but you'd have a difficult time convincing me that it's easier, and it is most certainly not faster.
Here's the bottom line: Some vi users accuse users of other (mostly GUI) editors of being technically-challenged simpletons. Some users of other (mostly GUI) editors accuse vi users of being anachronistic elitists. Both sides are wrong. An editor is a tool; use the one that fits you the best. Personally, I'll take vi any day, but that is my opinion (and it is for this reason that I qualify my statement with "personally.")
We're going down, in a spiral to the ground
I hate to bust your bubble but regexp is quite standard for any text search. If you ever leave emacs and do some real work with perl or bash scripting with awk and sed, then regexp knowledge is quite usefull. I consider it a standard actually and it shows me how standards compliant gvim is.
http://saveie6.com/
My two favoriate emacs vs vi jokes:
1.)VI is like masturbation. It may not be as good as the real thing but its always their if you need it
2.)Emacs is a great Operating System. It just comes with a crappy editor.
http://saveie6.com/
I thought it stood for "Eighty megs and constantly swapping".
http://saveie6.com/
$25.00 plus shipping (coverprice is $49.99)
http://www.addall.com/
remember to copy & paste the
ISBN 0735710015
Yes, I know, and that's the explanation I've seen for the names many times. However, I swear I heard mention that there was more to ls than the rest of them... that it was actually the authors initials. It must have been 5 or 6 years ago that I heard this and haven't seen any mention of it since.
I was starting to doubt that I had heard it at all when I saw the parent post saying the same thing. It's too big of a coincidence to just write off. Somebody else must have heard the same thing I did.
If anyone can corroborate that there is more to the naming of ls than simply LiSt, please let me know!
Thanks
load "linux",8,1
How about easy binding keys: :map <f1> <f12>
OK, if it can map the cursor keys to the requisite command sequence for moving the cursor; if it can map the return key to splitting the line like most other editors; if it can map ctrl-C to cut and paste, etc... in other words, if it can map out a more familiar and intuitive set of shortcuts than I wouldn't care so much to find an alternative. If somebody has a script that does that to VI, it would definitely go into my "gems" file.
How about knowing all the things it can do before making stupid comments on things you don't understand
I asked "what can it do?" You told me. Pretty straightforward, eh? Now, I could have sought out the information some other way, but asking people is far more efficient.
Obviously my post hit some raw nerves. Why else would (as of this moment) 13 people reply, and most with great passion in support of VI and against me as a person (even though they've never met me). Perhaps it has something to do with the fact that VI as the default *NIX editor has been one of the greatest stumbling blocks to wider acceptance of *NIX-like OSs is the larger community. Maybe it's just the criticizing such a thing is like walking through Harlem and shouting "nigger". I dunno. I'm not a shrink. Just chill out guys. It's a software. It sucks; just like all software.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
But does that mean that, at the end of the day, the MSVC++ editor is easier to use than vi? I don't think so. For example, if I want to delete 8 lines of text in vi, I simply type "8dd". Now, you might say "Well, all I have to do is take the mouse, highlight those eight lines, and choose Edit->Cut or press Delete or Control-C or Control-X or whatever", and you'd be right. And this may be more intuitive and familiar then pressing "8dd", but you'd have a difficult time convincing me that it's easier, and it is most certainly not faster.
I don't use MSVC like that. If I want to delete 8 lines of text in MSVC, all I have to do is hold down shift, move up 8 lines (with the cursor, not the mouse), and hit backspace. However, seldom do I want to delete "8 lines of text". It's far more likely that I want to delete "the foo function". If it were 8 lines, typing 8dd might not be so bad, but what if it's 17? How long does it take you to figure out how many lines it is? What if it's off edge of the screen?
Of course, this is just one example. Maybe someday I will see a savings in *using* vi and it will outweigh the cost of *learning* vi for me, but I've never found myself in a position where I was just totally cursing out the editor because it lacked a feature. Maybe I've just never been asked to do certain types of text processing. I dunno.
One thing is sure though; the last part of your post is golden, and should probably be in the FAQ for any group where editor flamewars break out on a routine basis.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I think the passion that you observe in these responses comes from a 'barbarians at the gate' mentality, and it's something I can really sympathise with.
Programs like vi, or find, or even TeX are very powerful, useful tools. But they're not intuitive to use - they require some effort. This effort though does seem worthwhile in many cases. On the other hand, there is certainly a notion extant that software must have an intuitive interface. When this is attempted, all too often the utility of the software is comprimised in the process. Sadly, even when this is a design principle, the software that results is often still unituitive, it just has a pretty GUI.
The prevalence of this view is a real worry to some, including myself. Good interface design is important, but good is not the same as GUI, or even necessarily intuitive. Peoples' intuition with software is not something they are born with, but develops through interaction with existing software. Metaphors such as the 'desktop' are in practice so far removed from their real-world counterparts as to be nigh on useless as an aid to intuition (they certainly have other benefits though!)
Having used something (like vi) which is powerful and useful, and then seeing a future where the vis of the world are replaced with harder-to-use (but prettier) applications, is disturbing and sad. So when posts such as yours appear, it touches upon a raw nerve. We're already in a state where many programmers are pretty much forced to use MSVC (for example) to practice their profession, MSVC luckily is relatively benign, but its close cousin SourceSafe certainly is not.
The attitude that something must be easy to be good, if it became universal, will be a tragedy of lost potential.
To misquote without attribution (I've forgotten who said it!), "Things should be made as simple as possible, but no simpler."
Sorry for the rambling response!
But have you never worked in a situation where you were one of several other junior sysadmins and not everyone else was as careful as yourself? Training people to use vipw and vigr is very useful in certain situations.
Also I don't really get your CVS vs RCS style locking point. Care to expand?