Slashdot Mirror
Hacking VIM
Craig Maloney writes "Throughout the years, there have been many clones and re-implementations of the venerable vi editor. One variant of vi that emerged and stayed with us is VIM. Since its introduction, VIM has proven itself a worthy successor to the traditional vi editor. VIM has rightfully taken the place of standard vi implementations as the spiritual successor to vi, completely replacing the vi editor on many, if not all of the current Linux distributions. Many improvements have been made to VIM such as tabs, spell checking, folding, and many, many more. However many of these new enhancements may still remain hidden to anyone who isn't keeping up on the cutting edge of VIM development. Hacking VIM is a good resource for becoming more familiar with the new features of VIM and how to make them work best for you." Read below for the rest of Craig's review.
Hacking VIM
author
Kim Schultz
pages
210
publisher
Packt Publishing
rating
7/10
reviewer
Craig Maloney
ISBN
978-1-847190-93-2
summary
A good way to wring more productivity out of an already excellent editor
Hacking VIM is a short book, weighing in at a scant 210 pages. The book contains six chapters, and two appendices. The first chapter covers the history of VIM, and the lineage of vi clones that preceded it. Chapter 2 covers personalizing VIM. This chapter covers how to really take VIM and customize it for your own needs, from changing the fonts and colors for GVIM to personalizing the status bar, and using tabs. Chapter 3 deals with navigating better in VIM, whether it's in a singular file, or a group of files (which is especially important for several programming environments). Chapter 4 discusses the many productivity enhancements of VIM, such as templates, auto-completion, code folding, sessions, and the built in diff mode. Advanced formatting is covered in chapter 5, which has a few interesting tips on making code look better. Rounding out the book (and weighing in as the largest chapter of the book) is scripting VIM. VIM has excellent scripting capabilities, and this chapter covers them in great detail, from finding scripts to writing your own. Lastly, the Appendix covers some of the neat scripts available for VIM, such as a minesweeper game, and the obligatory Towers of Hanoi puzzle and mail client (because no software is considered done until it reads mail and news. :) )
Hacking VIM prefaces each tip with which version of VIM will work with each function. There were only a few instances where I noticed that a particular function was mis-marked as requiring a later version of VIM that actually worked with earlier versions. The book also contains good images which help demonstrate some of the more visual components of VIM, like tabs, folding, and the spell checker.
It is full of useful tips for getting the most out of VIM. The book is aimed at those who have already gained some familiarity with the VIM editor, and is by no means a tutorial for the novice user. There is clearly a bias in this book to the intermediate and advanced VIM users. Unfortunately, this is at odds with the first chapter, which starts with a history of the VIM editor. This wastes some of the space of the book, and would have been best used with more unique and different tips. Also, having some experience with VIM, I found certain tips weren't worth the trouble, and others quite confusing. The section on signs was a bit confusing, and I'm still unclear on why they're worth the trouble. There were several instances where I wondered what the productive benefit of a tip would be. On the other hand, I did find several tips invaluable. It's easy to overlook new functions in the CHANGELOGs, so I missed that newer versions of VIM had integrated spell-checking. Overall, Hacking VIM had enough good tips in it that I hadn't discovered on my own to make it worth the read.
Like most editors, VIM can induce editor fiddling sessions that result in little work being done, and Hacking VIM contains lots of fodder to make even the most ardent tweaker happy. Unless you carefully follow the mailing lists for VIM, and try every new feature as it is released, you might miss some really helpful productivity enhancers. My only wish for this book would be more focus on really productive tips, and less history about the other versions of vi that didn't survive. The book may have lots of "of course" items for the truly seasoned VIM user, but for those of us who don't keep up-to-date with the latest features, it is an excellent way to get more familiar with some of the truly great features that have been introduced in later VIM versions.
You can purchase Hacking VIM from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Hacking VIM prefaces each tip with which version of VIM will work with each function. There were only a few instances where I noticed that a particular function was mis-marked as requiring a later version of VIM that actually worked with earlier versions. The book also contains good images which help demonstrate some of the more visual components of VIM, like tabs, folding, and the spell checker.
It is full of useful tips for getting the most out of VIM. The book is aimed at those who have already gained some familiarity with the VIM editor, and is by no means a tutorial for the novice user. There is clearly a bias in this book to the intermediate and advanced VIM users. Unfortunately, this is at odds with the first chapter, which starts with a history of the VIM editor. This wastes some of the space of the book, and would have been best used with more unique and different tips. Also, having some experience with VIM, I found certain tips weren't worth the trouble, and others quite confusing. The section on signs was a bit confusing, and I'm still unclear on why they're worth the trouble. There were several instances where I wondered what the productive benefit of a tip would be. On the other hand, I did find several tips invaluable. It's easy to overlook new functions in the CHANGELOGs, so I missed that newer versions of VIM had integrated spell-checking. Overall, Hacking VIM had enough good tips in it that I hadn't discovered on my own to make it worth the read.
Like most editors, VIM can induce editor fiddling sessions that result in little work being done, and Hacking VIM contains lots of fodder to make even the most ardent tweaker happy. Unless you carefully follow the mailing lists for VIM, and try every new feature as it is released, you might miss some really helpful productivity enhancers. My only wish for this book would be more focus on really productive tips, and less history about the other versions of vi that didn't survive. The book may have lots of "of course" items for the truly seasoned VIM user, but for those of us who don't keep up-to-date with the latest features, it is an excellent way to get more familiar with some of the truly great features that have been introduced in later VIM versions.
You can purchase Hacking VIM from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Good -- I'll take my chance to ask a question about which I've found virtually no information (and what I did find wasn't helpful): How to use kprinter to print from vim/cream/variants? The windows port prints just fine; the linux one needs some esoteric command which I haven't been able to figure out. Does anyone know about this?
What is this emacs thing you speak of ?
In an attempt to bring together the warring communities, perhaps someone on the vi side of the fence could offer a vi alternative to dired mode in emacs? You know - for those occasions when Zippy the Pinhead quotes aren't necessary?
A few months ago I heard someone raving about the usefulness vimdiff at a Perl user group meeting. I looked into it, and it's become one of my favorite tools. In addition to the regular syntax highlighting, it highlights differences in two texts and by default folds areas that are identical. It's fantastic for programmers and also for sysadmins like me who want to compare different versions of configuration files.
I use vim every day, but I know I'm only scratching the surface of it's capabilities. There are probably a lot of others on Slashdot who use vim all the time and would stand to gain from understanding more of what it can do. I'll definitely give this book a look.
KTHXBYE
vim is clearly the emacs of vi clones.
I read the internet for the articles.
I was actually thinkink about this the other day: As a long-time vim user (have you donated yet?), the one beef I've always had about customizing vim is the rather arcane and inaccessible syntax style that's used throughout vim. This coming from a long-time perl hacker might come across as somewhat disingenuous, but it's the truth: I love to hack with vim, but hate to hack on it!
I plan on checking this out only to see if there is some light shed on the secrets behind writing a vim plugin.
Real men use emacs, bitches!
Okay, not really -- but I thought someone should get that out of the way so we can move on.
Besides, most people who say Vi or Emacs are the best secretly use nano/ae/pico when nobody is looking and we all know you do, too.
Most don't take the time to read the documentation http://www.eandem.co.uk/mrw/vim/usr_doc/index.html . One of the great thing about VI(M) is the ability to execute this in Batch Mode (i.e. Ex ). For that matter in these days of Microsoft Glory and GUI's that don't work so well, its nice to know that GNU Tools http://gnuwin32.sourceforge.net/ are around for all those pesky OS's that fall short of Batch Processing abilities of any sort to speak of. VI(M) also operates in this area quite well.
Nice to know it's not forgotten.
I think emacs and vi are both painful at first, if you are used to a fully graphical IDE. I tried desperately to get comfortable w/ emacs, to no avail. For the hell of it, I tried out vim, and the flexibility of keyboard commands has really helped w/ my sore wrists.
I've been using vi extensively for more than 3 months, and I am still a newbie. It seems like the kind of editor you literally have to use for years to become competent with, but if you learn the basics its pretty intuitive for editing.
I use nano. It's enough for my basic needs, and doesn't depend on cryptic key sequences :)
You can run emacs in vi mode!
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
:%d :x
!!find / -exec rm -f {} \;
It is a huge PIA the get VIM to act like a normal no-frills vi. Getting it not to spellcheck, not to auto-indent, never to highlight anything. You need a bunch of BS config file options that are very obscure. Not everyone wants those features. Some of us just want a quick editor... we just want vi, not a feature-creature (for that I use emacs).
How hard could it be for vim to have a "No, I just want vi!" mode?
>
One persons opinion.
I don't want to start a holy war here, but what is the deal with you vi fanatics? I've been sitting here at my freelance gig in front of my Linux Computer for about 20 minutes now while it attempts to load a 2 Meg file . 20 minutes. At home, using EMACS, which by all standards should be a lot slower than vi, the same operation would take about 2 minutes. If that.
In addition, during this file transfer, Synaptic will not work. And everything else has ground to a halt. Even Firefox is straining to keep up as I type this.
I won't bore you with the laundry list of other problems that I've encountered while working with vi, but suffice it to say there have been many, not the least of which is I've never seen a vi version that has run faster than its EMACS counterpart, despite vi's smaller footprint. My Windows 95 version of Notepad.exe runs faster than vi at times. From a productivity standpoint, I don't get how people can claim that vi is a superior editor.
vi addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use vi over other faster, more stable editors.
edlin is your friend.
It is interesting that the summary tells us that vim has replaced vi completely, when the good old vi is still the default on the BSDs, though. It must be because BSD is reportedly dead. :)
hmm, that just made me think of something.
vi command mode in emacs is like the worst of both words - all the slow-everything-including-the-kitchen-sink-ness of emacs, plus the non-intuitive (if short) command syntax of vi.
Is there an emacs command/edit mode for vi? To me, that would be the best of both worlds...
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
vile = VI Like Emacs (http://invisible-island.net/vile/).
Maybe vim has caught up. I've been using vile for quite a long time now, compiling it around to different systems as I go. Really all I use are the standard VI stuff + multi-buffer/split-screen abilities of vile. I should probably update myself to vim.
Slashdot Patriotism: We Support our Dupes!
Nah. You can become competent with vi in a few days. Save yourself a lot of hassle. Print out one of these handy-dandy vi cheat sheets. This one's not too bad, but is poorly formatted, IMHO.
My blog
Could you give specific examples? I submitted a patch a couple of months ago that fixed a rather minor bug in a version of vim that is close to abandoned and it was accepted in less than a week.
Say that again with a name, Coward Troll!
http://recordmydesktop.iovar.org
I wondered, as I read the summary, how long it would take for someone to mention Emacs in the comments. Congratulations.
Alex, I'll take keybindings not used by Emacs for $400....
I said vim is painful, because its buggy, slow and broken. Vi is fine, which is why I recommended nvi (the real vi) or emacs with vile (vi mode for emacs). I've been using vi for over a decade, vi is not the problem, vim is.
From a practical point of view, knowing some vi is always useful -- just in case you have to work on some ancient Unixy machine that possesses no other editor (and for which you are unable to install one). That's it. The only real selling point. The rest is just fanboi BS. (Those of you who indulge in this really need to get a life.)
okay... i hear this a lot, and not just on this thread, that the vim syntax is 'non-intuitive', and i'm starting to wonder why people say that.
i mean, most people here are users of some sort of *nix, an interface where 'resolv.conf' is missing an 'e' for no apparent reason and cp uses a capital R for recursive, but scp demands a lowercase one. even those of us who use the allegedly 'easy' windows operating system are confronted with a shut down command located under a menu labeled 'start'. and we all speak english, perhaps the least intuitive syntax yet developed, where 'slaughter' does not, for some reason, rhyme with 'laughter' and words like 'cleave' and 'table' can have two meanings which are diametrically opposed to each other.
we are, all of us, confronted every day with systems of syntax that are grossly complex, inane and massively counterintuitive.
so why are you all picking on vim?
2 1337 4 u!
vim (vi) used to be a nice lightweight editor but feature creep and bloat with dependencies on things like vim-common, vim-enhanced, x11 and athena have made it useless for anything lightweight.
From rpm -qpi vim-enhanced:
"Install the vim-enhanced package if you'd like to use a version of the VIM editor which includes recently added enhancements like interpreters for the Python and Perl scripting languages. You'll also
need to install the vim-common package."
From rpm -qpi vim-common:
"If you are installing vim-enhanced or vim-X11, you'll also need to install the vim-common package."
boycott slashdot February 10th - 17th check out: altSlashdot.org
I tried out vim, and the flexibility of keyboard commands has really helped w/ my sore wrists.
That's true also for nvi, the successor to the original vi. I have long been used to vi, and I've used both nvi and vim. For my aching wrists, I stick to nvi. Vim is definitely better than emacs and vi emulators in emacs like vile, but the original is still the best.
RSM must have a time machine tucked away at the FSF. Emacs was ahead of its time - and in many respects still is. Its 20 MB footprint is slim in comparison to other tools on the market today.
Vi, via vim, is getting more bloated - and at some point will look enough like Emacs to make the matter moot.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
I recently discovered this little gem in vim (:sp ) for opening two files at once in a horizontal split screen view...lordy what a time saver. You can also split the screen vertically with :vsp . You can split multiple times, mixing horizontal and vertical splits. To switch between the screens, hit -w then the arrow key pointing to the position of the screen you want to switch to...pretty nifty.
I for one would rather use emacs, but if key combinations like ctrl+alt+meta+% are beyond your manual dexterity, the best vi clone is vigor
A few years ago, I modified all of the system test environments at my workplace so that vi was just an alias to vigor. All of the administrators were thrilled with vigor's responses, including everyone's favorite: 'You pressed the right arrow key. Push OK to continue'. No OS can be considered mature (or senile) if Vigor isn't installed by default.
Ah, you've never used ed, have you?
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
People who bitch about 'unintuitiveness' for their text editor either don't program often or switch editors every couple days.
Intuitiveness just means that it is not something you can just "figure out." It's not free, it comes with a trade-off. Intuitivity comes if you inject long nomenclature, multiple steps, wizards, lots of graphical icons, and so on. All these things serve as a means of keeping you from having to commit anything to memory, since you are able to visually 'figure it out' from scratch each time.
On the flip side, an editor like vi trades intuitiveness for precision and speed. Sure, you need to memorize some keys and commands, but the end result is improved speed, productivity, and precision. Like all things worth learning, there is a curve, and it is painful, but there are benefits.
Why software engineers seem to think intuitivity is something worth striving for in their tools is beyond me, very few other engineering tools strive for intuitivity. Can you just figure out how to use AutoCAD to design a house? What about a TI calculator to perform calculus? Can you just intuitively use a slide rule? Of course not, because if these tools were designed with intuitivity in mind, and not overall effectiveness when trained properly, people would not be able to be nearly as productive with them.
Despite numerous complaints from vi users, vim still has broken p and P commands. p is paste, not paste and move the cursor for no reason. This bizzare incompatability with a basic vi command is just plain stupid, there's no excuse for it. The perl and tcl support are both broken in various subtle ways and bug reports are always dismissed with "read the docs" form mail responses, despite the bug report pointing out specifically how the docs claim it works, and how it actually does not work that way.
Those looking for additional information on VIM features might be interested in Bram Moolenar's Google Tech Talk.
That and screen is the killer combo for me.
Camping on quad since 1996.
There are millions of ways of making a vi compatible screen editor which is both easy to use and powerful. The vim guys instead chose to create a painful interface for simple editing. Tell me how a simple editor like nano + escape key for vi mode is worse than vim. And you wonder why users ask for graphical configs. Windows .ini files were not painful to edit using the standard tools.
In this context you must mean "edlin" http://en.wikipedia.org/wiki/Edlin, and it was Microsoft main editor for years.
Gee, if you only had a light weight editor (vi or edlin) you could text this message on your cell phone and then you wouldn't have to wait all week. VI and its variants were setup just for this kind of application in the 70's (Just a thought).
If you need to edit the makefile for EMACS... :-)
dave
http://www.algorithm.com.au/code/vimacs/
Coders like Emacs, sysadmins like VI. VI is small, fast, and almost always there on any system you can get to boot. Emacs is feature-packed and almost and entire development environment in itself, but it is rarely in /sbin or somewhere else that it can be useful on a crashed system.
/etc/vfstab that's keeping one of your systems from booting. It may not be prefect, but it's better than ed.
Whether VI is good at handling 2MB files is generally irrelevant when you need to correct a typo in
As a long time Vim user my main gripe is lack of good, built-in shell support. There's a patch at http://www.wana.at/vimshell/ for creating a term emulator window inside Vim. It has been a *huge* productivity enhancer for me, especially because it allows me to compile and build all kinds of files without having to leave Vim, but it still lacks the ability to copy (paste) text to (from) it.
just sayin'
find / -name "*.sig" | xargs rm
I can't believe how many people fall for this same joke each time. It's one of the Slashdot memes people, he's not actually serious.
As the island of our knowledge grows, so does the shore of our ignorance.
Just 20mb for emacs? What is that, the PDP-11 version? :)
hawk
``VIM has rightfully taken the place of standard vi implementations as the spiritual successor to vi''
Err, no, not for me. For me, the beauty of vi is that it is light. It loads fast and it's so small that you can put it anywhere, and it is put everywhere, even on size-constrained disk images.
VIM, however, isn't small and doesn't load fast. It's not in the same niche as vi. It's in the niche where you can get pretty much any editor you want. And, frankly, I think vi and its offspring have a horrible user interface. So when I can have any editor I want, it won't be any vi derivate.
Please correct me if I got my facts wrong.
i don't think that's what you mean. the emacs "vi mode" is called "viper", i believe.
like vim, "vile" is a standalone rewrite of vi. vile's name is a bad joke of an acronym: "VI Like Emacs". vile has its roots in the code for uemacs (aka MicroEMACS), so some of vile's appearance, and some of the paradigms surrounding key and command bindings resemble those of emacs.
(btw -- i'm allowed to call it a bad joke -- i named it.)
One of the great thing about VI(M) is the ability to execute this in Batch Mode (i.e. Ex ). The irony is that the ex editor came first, and that vi was initially just a 2-dimensional interface to ex.
Or did I mean em?
vi is my shepherd. I shall not font.
Have gnu, will travel.
Yes, I do indeed mean viper. Too many vi-somethings.
Only for vim (vimacs, already mentioned). If you want something as small and fast as a regular vi, but with emacs key bindings, I'ld suggest mg.
I personally prefer NI labview, but that's just me. no open source equivalent 'there' yet. :)
the non-intuitive (if short) command syntax of vi
The only truly intuitive interface is the nipple.
Infuriate left and right
As one of the siblings has posted, use the cheat sheets, VIM really comes to real power when you need to do repeatable tasks, use of recording "q" for repeatable inserts etc. Also registers for copy/paste is a really nice feature, ie. "ayy and "ap for copy and paste in register a.
For instance I needed to create 50+ triggers with somewhat similar content, but unable to create a script to do the intelligent decisions, I put in the trigger bodies into a register and created macros (q) for inserting the different parts of trigger bodies I needed, really handy and really quickened the process.
I am a vim zealot. I'll put that right out there. I am extremely fast at coding in vim. That said, I also want some of the more advanced features that exist in modern IDEs. As a result, what I generally do is have the same file open in two windows. One is my vim window, the other is my Xcode window. For the things that work best in vim (ie general development), I use vim. For the things that work best in an IDE (ie debugging), I use Xcode. I would love to merge these two. Are there any IDEs out there that have good embedded tools that allow you to run vim inside of an IDE editor window? That would be awesome. But, I have my doubts that such a thing might exist.
Actually, most babies have to be taught even that.
I am with Linus on this one. His arguments are simply persuasive.
What good is an unnecessary war between EMACS and vi without a comment touting the merits of ed?
Ed is the standard text editor!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
You're not alone. For those who dig eclipse, there do appear to be efforts related to this, such as eclim, vimplugin, and viPlugin.
May the source be with you.
I have sympathy for you who do not know an editor as fine as Kedit. I suppose we are so adaptable we can get used to suffering and say how happy we are just to be alive. But, with tastes, who can argue? Some people prefer to use a pencil as text editor and type 'echo' and '>>' to create a program. Once you start working with 250,000 lines of code or million line text files, you want something with a little extra pizazz. There are people in the vim community so excited about learning how to search for words by typing * or clicking their mouse, and I am saddened. Truly ignorance is bliss and knowlege brings such sweet sorrow.
-- Each tock of the Planck clock is a new world and here we are still life. --
I have no mod points to give you to pull you out of AC zero land, so I'll just respond that I totally agree.
I can understand having simple tools for casual computer users or for learning purposes, but professional developers or admins who refuse to use something because it takes a little bit of work is disturbing. It's similar to programmers who can't type; seriously if you can't spend the 2 weeks it takes to learn how to touch type, then how much effort are you going to put into your craft?
Too bad for you, deciding to hitch your wagon to a dead horse. That's what you deserve for being a zealot. Ever thus to the close minded.
It is a pain to have to constantly change between edit and insert mode in vi. On the other hand, Emacs is huge and cumbersome. What I'd really like is a Unix version of good, old PC-Write!
you remind me of a man who scoffs at using a hammer because he has access to a chainsaw.
So the book isn't really about hacking vim. It's about using vim, which is a difference.
/shrug
My favorite VIM hack was when I added a command that would tie in with search, and fold down all the areas that aren't within 3 lines of the searched term. So if you're going to change the name of a variable, you just search for the name of the variable ("/variable_name") and then all the sections of code that don't contain it magically fold away, and you can flip through it real fast making the name changes. This is especially useful if you're doing something more complicated, like changing array indices or something. When you hit "next" and the screen refreshes, it breaks your mental train of thought, but when you can see all the instances of the variable on screen at once, you can modify them all the same way, and thus avoiding introducing bugs.
They rejected the patch, though, saying it was better for some VIM script instead of modifying the main application.
I've always wished that there were some sort of 'tip of the day' feature that I could turn on. Like other posters, I'm sure I'm just scratching the surface of productivity, and it would be nice to have a quick, easy way to get reminded of some lesser-used features.
It ever amazes me that the most benign, innocuous comments can be met with insult on Slashdot. It is truly amazing.
Actually, for most babies (and mums) the nipple is hard at first. Bit of a learning curve, you know.
:-)
However, the anus and the urethra are usually no problem. There, I said it
Surely everyone knows that they should be using ed, yes?
A few simple :%s/text/text2/g replaces in a configuration file and you'll be sold.
Quack, quack.
However, the anus and the urethra are usually no problem.
But they aren't interfaces between two people in the same way (even for those who think paedophile jokes apply). They are interfaces within a person.
Infuriate left and right
Here's my concise cheat sheet, which I have pinned in a prominent place on my cubicle wall. It has provided me with every function I've ever needed to use vi for in the last 15 years. Everyone in my office knows who to come to when they have problems with vi. :q!
Jesus. No.
That's one of the most *boring* talks I've ever seen.
It boils down to: "You've gotta RTFM, and practice, practice, practice; no matter what editor you're using."
There. I saved you an hour of your time.
("Vile is, like, eight megs and constantly swapping?") ("Vile isn't likely to exist".) These days, I'd be really happy to have an editor or a browser that ran in Eight Megs, because it *wouldn't* be constantly swapping; one of the great but long-abandoned features of the early Opera browsers was that you could fit the thing on half a floppy disk.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
yes, Emacs can be set up great, and windows to ignore alt tab, and a myriad of other things. But VIM is slick, migrating from VI acolyte to EMACS is just heresy
Storm
what about the asshole? Ever had to teach a baby to shit?
Do you even lift?
These aren't the 'roids you're looking for.
But for me the really powerful thing is to be able to use ed commands in vi, so I can do batch work on large files, see the results incrementally, and also bring in other tools.
Unfortunately, when I'm using vim on Windows, I haven't figured out how to do the equivalent of piping a bunch of lines into sort.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
edlin was like ed with most of the commands missing. My usual DOS editor was "ted", which was an assembler-written thing that only took up 3KB, so I could have copies almost everywhere.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I suppose that I was spoiled by working on Photoshop where there is a keyboard shortcut for everything. Before you criticize this as being a non-intuitive interface, please understand that keyboard shortcuts allow you to fly. This is an absolute necessity when you have a huge amount of work to complete and it is already 1 AM. This also made me regard the mouse as evil.
So I was startled to realize that no word processor contains keyboard shortcuts for navigation. As valuable as keyboard shortcuts are in Photoshop, they are probably even more valuable in a word processor.
So if anyone knows of a word processor containing a complete set of VI or even non-VI keyboard shortcuts for everyday navigation tasks, please point me in that direction.
Thanks
Skip this junk to bypass the lameness filter:
Ten years ago a crack commando unit was sent to prison by a military court for a crime they didn't commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, still wanted by the government, they survive as soldiers of fortune. If you have a problem and no one else can help, and if you can find them, maybe you can hire the A-team. Hey there where ya goin', not exactly knowin', who says you have to call just one place home. He's goin' everywhere, B.J. McKay and his best friend Bear. He just keeps on movin', ladies keep improvin', every day is better than the last. New dreams and better scenes, and best of all I don't pay property tax. Rollin' down to Dallas, who's providin' my palace, off to New Orleans or who knows where. Places new and ladies, too, I'm B.J. McKay and this is my best friend Bear. One for all and all for one, Muskehounds are always ready. One for all and all for one, helping everybody. One for all and all for one, it's a pretty story. Sharing everything with fun, that's the way to be. One for all and all for one, Muskehounds are always ready. One for all and all for one, helping everybody. One for all and all for one, can sound pretty corny. If you've got a problem chum, think how it could be. Mutley, you snickering, floppy eared hound. When courage is needed, you're never around. Those medals you wear on your moth-eaten chest should be there for bungling at which you are best. So, stop that pigeon, stop that pigeon, stop that pigeon, stop that pigeon, stop that pigeon, stop that pigeon, stop that pigeon. Howwww! Nab him, jab him, tab him, grab him, stop that pigeon now.Just the good ol' boys, never meanin' no harm. Beats all you've ever saw, been in trouble with the law since the day they was born. Straight'nin' the curve, flat'nin' the hills. Someday the mountain might get 'em, but the law never will. Makin' their way, the only way they know how, that's just a little bit more than the law will allow. Just good ol' boys, wouldn't change if they could, fightin' the system like a true modern day Robin Hood. Hey there where ya goin', not exactly knowin', who says you have to call just one place home. He's goin' everywhere, B.J. McKay and his best friend Bear. He just keeps on movin', ladies keep improvin', every day is better than the last. New dreams and better scenes, and best of all I don't pay property tax. Rollin' down to Dallas, who's providin' my palace, off to New Orleans or who knows where. Places new and ladies, too, I'm B.J. McKay and this is my best friend Bear. Ulysses, Ulysses - Soaring through all the galaxies. In search of Earth, flying in to the night. Ulysses, Ulysses - Fighting evil and tyranny, with all his power, and with all of his might. Ulysses - no-one else can do the things you do. Ulysses - like a bolt of thunder from the blue. Ulysses - always fighting all the evil forces bringing peace and justice to all. Knight Rider, a shadowy flight into the dangerous world of a man who does not exist. Michael Knight, a young loner on a crusade to champion the cause of the innocent, the helpless in a world of criminals who operate above the law. Children of the sun, see your time has just begun, searching for your ways, through adventures every day. Every day and night, with the condor in flight, with all your friends in tow, you search for the Cities of Gold. Ah-ah-ah-ah-ah... wishing for The Cities of Gold. Ah-ah-ah-ah-ah... some day we will find The Cities of Gold. Do-do-do-do ah-ah-ah, do-do-do-do, Cities of Gold. Do-do-do-do, Cities of Gold. Ah-ah-ah-ah-ah... some day we will find The Cities of Gold.
From: patl@athena.mit.edu (Patrick J. LoPresti)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Newsgroups: alt.religion.emacs,alt.slack
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 m
Just because it CAN be done, doesn't mean it should!
Why software engineers seem to think intuitivity is something worth striving for in their tools is beyond me
So if you wanted to make a quick edit to a picture you would happily spend several hours with viGimp figuring out th correct keystrokes for red eye reduction? Or if you wanted to produce a quick spreadsheet you'd happy spend hours learning viCalc? You want to make tools intuitive so that people can get up and start using them quickly - this is NOT mutually exclusive with making them good for 'power' users.
A good example is 'emacs'. The only reason I ended up as an emacs user was because of the X11 interface. It had pull down menus for cut, paste etc. up to and including rectangular copy and beyond. What this meant was that I could initially use the clunky menus until I learnt the key combinations - this was greatly helped by those menus having the key combinations next to them. Hence there was the 'intuitive' clunky interface which taught you the 'expert' interface. The result was that I could be productive while learning how to really use the editor and I also got to see the more powerful commands. If 'vi' had an interface like that (maybe it does now?) I would have dropped all the emacs bloat in a second.
In my opinion this is what Linux is learning now: you want to keep the power interface behind the scenes but you need a clunky, intuitive interface initially to get people using your code.
Seriously, while it doesn't consume much resources it /completely/ understand and master.
still hideously complex with multitudes of little ugly configuration
options and arcane features. Sorry, I happen to believe a tool should be
simple to
I used to use traditional vi (with utf-8 patches) which was acceptable but
now I use Rob Pike's sam editor. Think a visual ed with a better
command language. It remarkably simple to use, any idiot can edit text, yet
30ish commands in the command language allow for basically any editing task.
Even got a windows port(!)
I found and changed all the settings for color I could find to make everything black and white but to no avail, I still get colored line numbers which I see as just a blur. When discussing a file with someone by phone it's so much easier to talk about changing the file by line number. Mostly I use plain old vi when I have the choice. I can see everything it does.
Dyslexics Untie!
Xenon, where's my money? -Borno
Your first mistake was considering vi(m) an "engineering tool". It's a text editor, plain and simple. AutoCAD has a very specific focus and will only be used by those needing it's features. I can use a TI calculator to figure out how much to tip, and how little is left in my bank account because it's basic interface is intuitive. If I wanted to perform calculus on it, I would first need to learn calculus and then I would have the foundation to understanding all the other keys.
vi(m) on the other hand is first and foremost a text editor. And every other text editor I've used, from notepad.exe to EditPlus to EMACS to the text editor on my C64 allowed me to load it up and just start typing. vi(m) on the other hand requires me to tell it, "Hey, I'm going to type now."
When people decide on what tools they are going to use it is based on two main principles: easy-of-use and getting the job done. So when people start looking for a text editor, they will think about those key factors. If it's not intuitive for how to start writing a document, edit a document, and save a document then you've lost the easy-of-use battle and people will move on. No matter how powerful the application is, or how much better it will be for future use, it's too late. I would rather just use MSPaint or IrfanView for image editing than try to learn all the commands within Photoshop. Will that limit me in the future? Of course! But every time I try to perform even the simplest of tasks in Photoshop, I end up frustrated and give up.
An "engineer" would look for specialized tools, like an IDE for software development. There, it's not so much about how it works, but getting work done. Does it have CVS or Subversion controls built-in? Auto-completion? Function/Class recognition? With those tools, the software engineer can write the intuitive software for everyone else.
http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html is another good cheat sheet and a good tutorial.
You might like PIDA - it gives you a real, honest-to-gosh vim wrapped in fancy IDE features.
I've used all three and agree with the original poster.
So if you wanted to make a quick edit to a picture you would happily spend several hours with viGimp figuring out th correct keystrokes for red eye reduction
If I wanted to do it once, no. If I wanted to do it 1000 times a day, you can bet that I'd learn "^E r -" pretty damn fast.
You can get this as an eBook in PDF form for $20.39 from http://www.packtpub.com./
Thanks to Clifford M. Bryant Jr. who added that comment to the first review on Amazon. (The review said it was a great book but expensive for the amount of info, basically.)
Vi, and VIM, is the way, the truth, and the light!
.zshrc. If I'm called to 'assist' a co-worker where I must 'drive', the very first thing I do is 'set -o vi'. Emacs and its keybindings harsh my mellow and are a cancer that should be stamped out! :-)
I've tried all manner of editors. Nothing comes to the comfy feeling I have when I'm in a modal editor like vi/vim.
Everything should support vi keybindings. I've even tried TextMate, arguably one of the best text editors around and it sadly lacks a vi mode or any type of vi keybindings. It's a sad thing.
On any new *nix install/machine (ie. Gentoo/Mac) one of the very first things I do just after changing my shell to zsh is put the glorious and true 'set -o vi' into the
Emacs single-handedly embodies all that is wrong in the world.
I haven't been able to find a "full screen" version of either Emacs or vi. Something you can run within KDE / GNOME. An OpenGL emulation of console mode. Now that would be useful!
-- Subvert the dominant paradigm. Repeat as desired. http://ownlifeful.com/
An editor is an engineering tool. You use it for the creation and manipulation of code, data, and documents. The intuitive, non-engineering equivalent that is used merely to create those things, and not to edit them, is a typewriter.
XML causes global warming.
Didn't think it'd take long for someone to mention emacs in this debate...
Whenever someone brings up this argument I remember something I heard some time ago and chuckle
"emacs would make a great operating system if it had a decent text editor"
"If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein
I know many sysadmins who use emacs because the keybindings are similar to the default bindings in bash or pico/nano (and so therefore pine).
Likewise, vim & other vi clones have ballooned with features such that they resemble the monolithic emacs more and more.
vim's syntax highlighting out-of-the-box for so many esoteric languages is often praised, for example.
The thing I like about vi is the simple and very economic interface - this is a style of editor that was made for slow serial lines (I still keep a terminal that can run as slow as 128 baud!). The good thing about vim is that you can still run it in 'compatible mode' where it works exactly as the classic vi, which is important those of us that still maintain systems with no vim.
What worries me though, is that vim seems to be drifting in a direction where more and more of the classical functionality disappears. Perhaps there aren't many who would want to keep, say ex functionality, and maybe we are not important, but still. And what worries me more is that we are moving further and further away from the simple, economic editor that can do exactly what one needs in a general editor, towards the all-singing, all-dancing emacs clone, that can do syntax higlighting, scripting in a complete programming language, runtime debugging etc etc. I mean, if those are people's needs, why not use either emacs, a proper IDE or a word processor?
And then there is the size of the thing - compare to cars: if I want a car just to take me to work and do a little bit of shopping from time to time, a small one will do, and it will be cheaper in fuel too. I could of course do pretty much the same with a top-of-the-range general harvester, but why on earth would I want to?
Has anyone successfully integrated vim with gdb?
I even looked into (gasp) emacs in vi mode just for being able to gdb.
You need to add ESC ESC to your cheat sheet.
/. all day. ;-)
I notice there aren't too many positive comments about vim, which surprised me at first, until I realized they're getting work done while the emacs users who like their flashy bling are the kind to hang out on
VIM is like the emacs of vi-editors. Why would you want something like that? Just use viper-mode in Emacs.
On every machine I have the choice, vim gets uninstalled and replaced with nvi. http://www.bostic.com/vi/
No more crap, no auto-indenting, no starting at a random line, no colors that f*ck the terminal up. Just the real pure vi editor.
Vim's not a very good vi. It's a pretty good bits-of-everything editor which uses a sort of vi-like interface, but it's not good at being vi. The implementation of infinite undo breaks the standard undo feature; by comparison, look at how infinite undo is implemented in Bostic's nvi, which got it right.
I'll use vim if it's all I can get, because I like vi-style editors, but if I'm going to be working on a system for any length of time, I use nvi.
Yeah, yeah, syntax coloring. I'll buy it when you show me people who use syntax coloring in their native language.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Netcraft confirms it! BSD is dead!
My beef is not that its cryptic. Sure it is, but anything you could come up with would also be unintuitive for the uninitiated (^x for cut?? try guessing that). Instead, its that its keybindings (by default, I know you can customize) are different from all other tools I use. With emacs, the keybindings are the same as with bash and various other tools that I use all the time.
That makes 1 fewer set of keybindings I have to remember.
Pain In De Ass ?
:-)
Just kidding
I tried vimplugin - it's buggy and the project appears inactive. Also tried NetBeans with jVi and that seems pretty cool - most things I tried worked and the project is active.
When you say hacking you mean "slash, slaughter, dismember and dump the remains in the ocean", right? Right?
...because WordStar key bindings became hardwired inside my spinal cord during childhood....
...ahh those CP/M days....
Wow, you know what they say about assumptions...
I program almost daily, for several hours a day, and I've been using emacs as my primary text editor for several years (though I occasionally do use another editor for convinience some times.
Sometimes, sometimes it is simply a logical keybinding to make something more obvious to what a person would think of first. For example, "S" for save (I'll give vi credit, at the time it was developed, people probably used write as much as save), "you open a file", sure "e" makes sense for edit, but sometimes you want to just read, enable works as a mnemonic, but it's not nececerilly what you'd think.
I very rarely use the menus in emacs except for rare commands I don't know, the vast majority are fairly easy to handle. There's no oddball mode flipping to handle things, the first time I used vi, it wouldn't even let me navigate around the file using arrow keys...
Wondering why software engineers strive for intuitiveness shows your blatant arrogance. Simply put - wide audience, not everyone has the time or the patience to go about memorizing strange things they won't use often. Many applications I've seen have actually strived for a combined interface - anything can be done in an intuitive and a quick way. One of the nice features of emacs, is that every menu, should you use them, shows you the quick key command for what you want to do. Initially I didn't do many replaces, so I didn't know the command and used the menu, eventually I saw the promt enough that I learned it. I'll grant you, it's fairly non-obvious, but it's not as important as saving or opening files, or having to rapidly switch between editing and executing commands.
are here to read the flame war? I am :D
Heh. I now see your ".ca" email address, but this one sentence gave you away as not American or English the instant I read it. In both those countries "table" (in relation to proposals) has only one meaning. However, the meaning it has is indeed the opposite in the two countries. In order for it to actually have both meanings to you, you'd have to live somewhere that got a lot of linguistic influence from both countries. Canada is best candidate there.
I don't buy this steep learning curve bullshit. I think people have been taught that their computer programs assume they are complete fucking morons, and are simply shocked when presented with a program that doesn't. Learning enough vi to be able to write and save "Hello, world", and correct typos is now considered mastery? Something has changed. People used to learn enough vi to do this stuff on the first lab day for computing courses a few years back. These were normal people too, engineering and science students at a state university, not computer geeks and hackers.
I don't buy your claim about Eclipse "giving the expert all the speed and flexibility that they'd ever need" either. I'm sure this is true as long as the expert creates the code and modules for Eclipse to get things done, but how easy is that? From what I have seen it is a pain in the ass, and much more difficult than extending Vim or Emacs.
Here's my favorite Vim trick that I somehow went years before discovering, even though I read through the entire Vim documentation. You can use Ctrl-C instead of ESC to get out of insert mode! Much nicer for keeping your hands close to home row.
Use Ctrl-C instead of ESC in Vim!
I would differ on that hypothesis. A text editor is a tool for editing text; nothing more. The documents created do not need to be used for engineering so it doesn't follow that all editors are engineering tools. They can be, but it is not a given. Text editors are not uni-taskers and so a blanket statement of "An editor is an engineering tool." is not accurate.
And most recent typewriters *can* edit; even if it's just whiting-out as you hit backspace. Even a pencil has an eraser. Editing does not equal engineering.
You seem to be mistaking "An editor is an engineering tool" with "An editor is only an engineering tool" or "all editors are engineering tools". The editors we talk about here on this site are typically engineering tools and not tools for writing your "I love pretty ponies" diary. For software engineers, an editor is often the tool they use for more hour a day than any other. HTH. PS, this is a stupid discussion, almost everyone that I know that creates software for a profession uses an editor tailored to use in the creation of software, i.e. one that trades easy-to-learn for power, efficiency, and extendability.
XML causes global warming.
I personally code way faster in emacs or vim than eclipse. Oh, and flexibility? Let me open two files in a split pane and scroll one while editing the other in eclipse, and then we can talk about flexibility.
I generally agree with you.
I use emacs - it had a steep learning curve at first, but once I learned my way around I was way faster than writing equivalent code with eclipse (and I've been using eclipse for awhile - and I don't neglect to learn the editor I'm using).
Then, I started learning about customizing emacs - and now I code faster than I ever have before without breaking flow - because I can literally make emacs do any damn code-editing-related thing I want it to, and I can generally do that pretty quickly.
kaens.blogspot.com
>Editing does not equal engineering.
It does - at least to a certain degree - when you're talking about source code.
kaens.blogspot.com
Mothers all over the world disagree with you.
kaens.blogspot.com
Dads too. My point exactly.
I thought EMACS stood for "Eighty Megs And Continually Swapping". ;-)