Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hacking Vim 7.2

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Books 246

briancarper writes "Vim is an open-source text editor with a power and flexibility matched only by the steepness of its learning curve. As the author of this book states, 'Vim Can Do Everything' but configuring it to do so is sometimes daunting. Hacking Vim 7.2 aims to help the average Vimmer get the most out of customizing Vim, for fun and productivity." Read on for the rest of briancarper's review.Vim has an overwhelming number of features. Its built-in help system and documentation are comprehensive and easy to navigate once you know what you're looking for, but knowing where to start is sometimes very difficult. The best you can hope for in a book is a broad outline to point the way toward features that you didn't know much about. Hacking Vim 7.2 achieves this goal.

No topic is covered in nearly the depth you'll find in the official documentation (or even on the Vim Wiki), but every topic is covered in enough detail to let you know that a feature exists and to point you in the right direction to begin using it. Most helpfully, throughout the book are references to things to look up in Vim's help system, as well as links to various relevant scripts.

This is not a book for an absolute Vim beginner; some familiarity with Vim is assumed. And for a Vim fanatic, much of the material may be common knowledge for you already. But any seasoned Vimmer will tell you that there are always things to learn about this editor, and I think nearly everyone will learn something from this book. For someone who uses Vim and is looking to master it, this book is a great starting point, though you'll still need to dive into the official reference material to really cement your knowledge.

The book starts on an odd note. Chapter 1 is a history of vi and the various vi clones released over the past couple decades. This information is interesting trivia and serves to give credit to programmers who paved the road to Vim, but it doesn't really help anyone "hack Vim" in any way. The book probably could've done without this chapter.

Chapter 2 deals with customizing the overall look and feel of Vim. How and where to edit vimrc is covered, with brief attention given to cross-platform issues. It covers the basics (changing font faces and colors, customizing menus and toolbars), as well as pointing out some more obscure settings, like highlighting the cursor row and column (creating a kind of "cursor crosshair"), and using the match feature to highlight multiple search terms at once. This chapter is a good foundation for later chapters and a good introduction for anyone who has never edited their own vimrc.

Chapter 3 is about text navigation. Sadly, the book doesn't go into as much detail on movement commands as I would've liked. The ability to move around and manipulate text quickly in Normal Mode by combining counts and motions/operators is one of Vim's most unique and powerful features, but it only gets a few paragraphs here.

There are some interesting key mappings provided, for example how to move up and down between "virtual" lines when lines are soft-wrapped. Search is covered briefly, both plain text search and multi-file search via vimgrep, but there's little information about Vim's powerful regular expressions, which I thought was a shame. Marks are discussed, both normal "hidden" marks as well as visible "signs", the latter being a feature I've never used.

Chapter 4 is about "production boosters" and covers a wide variety of topics. Much of the chapter is devoted to "templates" and "snippets", which allow you to build skeletons of commonly-used source code (with fill-in-the-blanks markers) that can be re-used when editing new files. A system for using these templates is built from scratch using Vim script, providing a clever and useful example of scripting in action.

Auto-completion is covered in a lot of detail. Some custom key mappings are provided to help make "omni-completion" in Vim a bit easier to invoke. This chapter also very thoroughly covers Vim's multiple copy/paste registers and how they work. Recording and using macros, pointed out as one of Vim's more overlooked features, gets a good, lengthy example.

"Undo branching" in Vim is wonderful, but difficult to understand. Chapter 4 gives a simple, step-by-step example of why it's useful and how it works. This chapter also briefly discusses folding, vimdiff, netrw (editing files remotely via SSH and other protocols), and ctags. There's lots of good stuff in this chapter and you're almost certain to learn something useful.

Chapter 5 covers text formatting, both using built-in Vim commands and by piping text through external tools like par and tidy. A lot of space is devoted to using Vim to prettify plaintext, for example by centering titles on a line, adding ASCII-art dashes for headers and making bulleted lists. If you edit plaintext in Vim often, this is probably a great chapter, but I didn't find much use for most of it.

For programmers, the book discusses the different indentation styles available in Vim and very briefly shows how to write your own indentation functions, and how to indent and reformat blocks or whole files of code all at once. "Paste mode" also gets a passing mention. Personally I think a programmer reading this book would've benefited from much more detail about Vim's myriad indentation and text-wrapping options and how they work together, as this can be one of the most frustrating parts of Vim to configure correctly.

I had high hopes for Chapter 6 and 7, which deal with Vim scripting, but I was largely disappointed. Chapter 6 deals with scripting basics, and is essentially a beginner's language tutorial. It explains which variable types exist in Vim script, how if/then/else works, how for- and while-loops work, how function parameters operate, and so on, but anyone who knows a modern scripting language will learn these things quickly without much effort. There's also some basic information about how to write a syntax-highlighting script from scratch, but there's not really enough information to allow you write one for a real programming language.

Chapter 7 is supposed to be about "extended scripting" topics, but serves largely as a style guide. It details how to structure a script to check for compiled-in features and Vim version number. This chapter touches briefly on using SID and PLUG to namespace functions, but the explanation and example left me puzzled. How to use the debugger and how to make Vimballs are both explored, and the book points out that you can use Perl, Python and Ruby to script Vim without going into much detail or giving solid examples.

If you're looking for any advancing information on writing your own functions in Vim script, you're mostly out of luck here. Previous chapters in the book do include some useful and practical functions, but those functions are never really taken apart or explained in detail.

Finally there are two appendices, one of which lists a bunch of games you can play in Vim (again this could've been left out of the book and I wouldn't have missed it), as well as examples of using Vim as a mail, chat, and Twitter client. There's also a feature-by-feature comparison of Vim to MS Visual Studio, showing that many of Visual Studio's abilities can be provided in Vim given the proper scripts. I thought it was an interesting demonstration that Vim really can do everything, just in case the reader had any doubts at this point. The last appendix is a style guide for keeping your vimrc clean, mostly via common sense and splitting your configuration into multiple files.

Overall, stylistically the book is a bit dry and humorless, but it's easy enough to read and it gets its information across clearly. There were a few typos and editing errors, including a few rather glaring typos in some code examples, but overall the author seems extremely knowledgeable about Vim. The best parts of the book are where the author says "this was useful to me personally, so here's how I do X". This book is clearly written by someone who uses Vim all the time, and most of the information provided is practical and immediately usable.

I do feel the book should've gone into more detail in many areas. At 244 pages, the book is short and gives a rather shallow view of many of Vim's features. But the book hits all the right notes and leaves few features entirely unexplored.

I'd recommend this book to any person who uses Vim and wants to explore features they may have been missing. There's nothing in this book you won't find in Vim's built-in documentation, but this book lays everything out in an easy-to-read format, and should serve as a good starting point to customizing and mastering Vim.

You can purchase Hacking Vim 7.2 from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

246 comments

Sorry! There are no comments related to the filter you selected.

but... (1, Interesting)

Keebler71 (520908) | more than 4 years ago | (#32159402)

but does it tell you how to pronounce "Vim"??? (first post?)

Re:but... (2, Funny)

Keebler71 (520908) | more than 4 years ago | (#32159528)

I'm actually being serious... at great loss of nerd-cred... I've always wondered if it is pronounced "vim", "five-immm" or "six-mmm" or is the "i" sound a hard "I"? I've used to use it a lot when I had a linux file server in the house but it is not a word that has ever come up in casual conversation so I've never had a need to actually know...

Re:but... (4, Informative)

c++0xFF (1758032) | more than 4 years ago | (#32159560)

I've always pronounced it with vim and vigor. That seems to help.

Re:but... (1)

Nadaka (224565) | more than 4 years ago | (#32159794)

I have always pronounced vi as (Vv eye). So i would pronounce vim as Vyme (Vv eye mm). like vine, but with an m.

Re:but... (1)

just_another_sean (919159) | more than 4 years ago | (#32160526)

Hmm, I always heard vi was supposed to be pronounced "vee eye" so I always
say the whole name when speaking about Vim, therefore "vee eye improved".

Not sure it's right though and I suddenly feel like just saying Vim (as
in your vim and vigor example that is) would have saved me at least a
small portion of my time over the years! :-)

Re:but... (4, Informative)

swanzilla (1458281) | more than 4 years ago | (#32159748)

Vim stemmed from vi, which was never pronounced "six", so mostly, you are barking up the wrong tree. Vim is loosely "Vi IMproved" and the "i" sound is a soft "i" by convention.

Re:but... (1)

sconeu (64226) | more than 4 years ago | (#32160166)

Well, it has been pronounced "six", but only as a joke [userfriendly.org] .

Re:but... (0, Offtopic)

morgan_greywolf (835522) | more than 4 years ago | (#32159556)

but does it tell you how to pronounce "Vim"??? (first post?)

Yup! You pronounce it "ee - mah - ks".

Re:but... (0)

Anonymous Coward | more than 4 years ago | (#32159708)

I pronounce it like "veem"

Re:but... (1)

Idiomatick (976696) | more than 4 years ago | (#32159842)

Rhymes with rim.

Re:but... (1)

Tawnos (1030370) | more than 4 years ago | (#32160376)

And is often the best way to get the job done.

Why are you looking at me like that?

Short version (5, Funny)

Anonymous Coward | more than 4 years ago | (#32159500)

Use EMACS

Re:Short version (5, Funny)

Anonymous Coward | more than 4 years ago | (#32159636)

I'm trying! It's been loading since 2005, so give me some more time dude.

Re:Short version (4, Funny)

Tetsujin (103070) | more than 4 years ago | (#32159818)

I'm trying! It's been loading since 2005, so give me some more time dude.

See, there's your problem... Rather than wait five years for it to load, you should have waited a year or two, upgraded your machine, and tried again. :)

Re:Short version (0, Offtopic)

eviloverlordx (99809) | more than 4 years ago | (#32159806)

Hold on, I need to set up my Beowulf cluster just to run it...

Re:Short version (4, Funny)

eln (21727) | more than 4 years ago | (#32159810)

Use EMACS

But I already have an OS, why would I want to install another one just to edit text?

Re:Short version (1)

K. S. Kyosuke (729550) | more than 4 years ago | (#32160298)

And we already have physical machines, so why should we install Java and .NET virtual machines just to run software? I.e., this way, your text processing code can run on two dozens of platforms, on some of which there is no better alternative as far as sane text editing is concerned. Add to this the surprisingly sane XML editing functions of Emacs and you've won big time if you have to hack XML configs etc. at least from time to time.

Re:Short version (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32160488)

why should we install Java and .NET virtual machines just to run software?

We don't.

Re:Short version (3, Funny)

yuriyg (926419) | more than 4 years ago | (#32159854)

I tried Emacs a while ago. While I found it to be a superb operating system, I couldn't find a good text editor for it.

Re:Short version (0)

Anonymous Coward | more than 4 years ago | (#32159996)

HAHAHA.

Re:Short version (1)

Marcika (1003625) | more than 4 years ago | (#32160128)

I tried Emacs a while ago. While I found it to be a superb operating system, I couldn't find a good text editor for it.

You can open the text editor in Emacs by typing "M-x viper-mode". HTH.

Obligatory Response (0, Redundant)

MozeeToby (1163751) | more than 4 years ago | (#32159886)

We all know EMACS is a great OS, but what it really needs is a text editor.

Re:Short version (1)

Svippy (876087) | more than 4 years ago | (#32160522)

Real men use ed.

Bloatware? (0)

Anonymous Coward | more than 4 years ago | (#32159558)

First things first: VIM is a wonderful tool and I use it almost daily, for hours a day.

But I'm getting a bit miffed by all the cruft that's added. From a lean and mean editor it is growing into a bloated monstrosity. If I wanted that I'd just as well use Emacs...

What I would like is a way to compile in (or rather, to leave out) all the gimmicky stuff I never use anyway. That way it loads faster and is a much more responsive tool.

Re:Bloatware? (3, Interesting)

Jason Quinn (1281884) | more than 4 years ago | (#32159876)

I just trying starting up and shutting down vim a few times on an old machine. There was absolutely no noticeable startup time. This is on an older machine that was running *simulations* in the background. Just exaclty how much faster do you want it to load?

Re:Bloatware? (3, Informative)

beleriand (22608) | more than 4 years ago | (#32160062)

If you ever look at :version, it spits out this huge list of features, each with a "+/-" in front.

I suppose when you build your own custom verion, there is a way that you can configure your version to leave most of those features out.

In fact debian seems to have done just that, they ship "vim.tiny" in the base install with just 640k, which should be enough for everyone.

Re:Bloatware? (1)

ThePhilips (752041) | more than 4 years ago | (#32160224)

Add :filetype off to your .vimrc. That should disable most of the cruft.

Last bit is this (sorry for ma poor Engrish) [blogspot.com] .

To lesser extent, but yes, VIM is slowly getting more and more bloated - more and more time one has to invest into disabling all the annoyances. Though it is still worth it. (Unlike Emacs, where you can't configure much. You either take it as a whole or look for another editor.)

That word... he doesn't seem to know what it means (4, Interesting)

clone53421 (1310749) | more than 4 years ago | (#32159574)

Customizing something is not “hacking” it. Hacking something is taking it and using it to do something that it wasn’t originally designed for in a creative way that most people would never think of.

This is the only part of the book that is illustrative of “hacking” Vim:

Finally there are two appendices, one of which lists a bunch of games you can play in Vim (again this could've been left out of the book and I wouldn't have missed it), as well as examples of using Vim as a mail, chat, and Twitter client. There's also a feature-by-feature comparison of Vim to MS Visual Studio, showing that many of Visual Studio's abilities can be provided in Vim given the proper scripts. I thought it was an interesting demonstration that Vim really can do everything, just in case the reader had any doubts at this point.

Re:That word... he doesn't seem to know what it me (1)

clone53421 (1310749) | more than 4 years ago | (#32159718)

That was directed at the author of the book, by the way, not the reviewer or Slashdot editor who posted the story.

Additionally, I think she’s a woman, although the extra letter in “she” wouldn’t have fit in the size limit for the subject of my post. (“Kim” could be either male or female but I looked on Google and it seems her full name is Kimberly.)

Re:That word... he doesn't seem to know what it me (0, Offtopic)

jd (1658) | more than 4 years ago | (#32159758)

Kim Kimberley. Wasn't she the detective in the Level 9 adventure Snowball?

Re:That word... he doesn't seem to know what it me (3, Funny)

NonUniqueNickname (1459477) | more than 4 years ago | (#32159752)

for fun and productivity

That's two counts of *hacking* right there. As vim wasn't originally designed for either use.

Re:That word... he doesn't seem to know what it me (1, Informative)

Anonymous Coward | more than 4 years ago | (#32159962)

Re:That word... he doesn't seem to know what it me (1)

clone53421 (1310749) | more than 4 years ago | (#32160046)

I’ll see your Jargon File link and raise you three more.

http://catb.org/jargon/html/N/neat-hack.html [catb.org] , sense 1
http://catb.org/jargon/html/H/hacker.html [catb.org] , senses 1 & 7
and http://catb.org/jargon/html/meaning-of-hack.html [catb.org] .

You know you're doing something wrong when (0, Insightful)

Anonymous Coward | more than 4 years ago | (#32159588)

... you have to hack your text editor

Re:You know you're doing something wrong when (4, Insightful)

John Whitley (6067) | more than 4 years ago | (#32159724)

How on earth is this insightful? I don't know of a single software dev who doesn't end up adding significant hacks/customizations to their editor to make the tool fit their working style better. There's even a nice spectrum in most popular dev editors between "customize" and "hack" -- which goes right up through the occasional feature addition or bug fix in the app itself.

Re:You know you're doing something wrong when (0)

Anonymous Coward | more than 4 years ago | (#32160126)

Personally I prefer to concentrate on solving the problem at hand instead of thinking of ways I can waste time playing with toys.

Re:You know you're doing something wrong when (1)

ljw1004 (764174) | more than 4 years ago | (#32160520)

I suspect most users of Visual Studio don't add significant hacks (other than installing third-party plugins like Resharper)

Re:You know you're doing something wrong when (5, Funny)

IICV (652597) | more than 4 years ago | (#32159732)

... you finish your subject in the comment body

Mod parent (5, Funny)

Tetsujin (103070) | more than 4 years ago | (#32159834)

up

Re:Mod parent (1)

DJ Jones (997846) | more than 4 years ago | (#32159920)

... You moderate by posting a comment

Re:Mod parent (1)

IICV (652597) | more than 4 years ago | (#32160278)

-1 wooosh

The subject's changed, so you have to change how you finish it. Duh.

Re:You know you're doing something wrong when (1)

clone53421 (1310749) | more than 4 years ago | (#32159868)

He didn’t finish his subject in the comment body of his post, he started his comment in the subject line of his post. There’s a difference.

Re:You know you're doing something wrong when (0)

Anonymous Coward | more than 4 years ago | (#32160068)

He didn’t finish his subject in the comment body of his post, he started his comment in the subject line of his post. There’s a difference.

Much like the difference between you and a comedian. You make jokes. Comedians make people laugh.

Re:You know you're doing something wrong when (1)

clone53421 (1310749) | more than 4 years ago | (#32160146)

Unlike you, I wasn’t trying to be funny.

Don't tell me (0)

Anonymous Coward | more than 4 years ago | (#32160408)

... what I did in the first post. I finished the subject in the body. I did it on purpose. And I will do it again.

Re:You know you're doing something wrong when (1)

idontgno (624372) | more than 4 years ago | (#32159824)

You know you're doing something right when you can hack your editor.

You know there's something terribly wrong with you when you don't feel the urge to hack your editor.

Don't confuse those.

Wow (2, Insightful)

Anonymous Coward | more than 4 years ago | (#32159590)

Vim has an overwhelming number of features. Its built-in help system and documentation are comprehensive and easy to navigate once you know what you're looking for, but knowing where to start is sometimes very difficult.

It's really intuitive, once you get to know how to use it.

Re:Wow (2, Insightful)

Tetsujin (103070) | more than 4 years ago | (#32160008)

Vim has an overwhelming number of features. Its built-in help system and documentation are comprehensive and easy to navigate once you know what you're looking for, but knowing where to start is sometimes very difficult.

It's really intuitive, once you get to know how to use it.

I hate to ruin a perfectly good joke by being all serious, but, actually, that would be true of a lot of applications. (Or, perhaps, it's not accurate to call them intuitive at all - rather, they just offer enough support via documentation, etc. to help you muddle through) Anything that's hard to get started with, but offers a lot of assistance once you're up and running. I'd say Emacs fits this description to some extent - cryptic keyboard shortcuts (which are quite handy once you learn 'em) - and then there's commands you can search for, and even execute, by name. It's handy when I have a pretty good idea what the command name might be, but not what the shortcut is, or where it's located in the menu system or customization system, etc. I'd say the same could be true of MS Word as well - it confronts you immediately with a wall of controls, and it can be hard to find your way around, but it also offers a lot of support. Then there's specialized applications, content creation stuff especially like Photoshop or 3DS Max - which can be complicated just due to the amount of power they offer... There's a lot to learn, in other words, but the application helps you to learn it.

Re:Wow (1)

ThePhilips (752041) | more than 4 years ago | (#32160444)

Very true.

Sounds bit stupid, but in VIM one has to learn even how to type text.

When I started with Linux 10+ years ago, I have dedicated two weeks to each: Emacs and VIM. Everybody had recommended Emacs, but after spending two weeks with it, reading mail lists and talking to devels I still couldn't configure it to work as I wanted it to. Next came VIM and it really took me two days to learn the basics and how configure it to my liking - and start working efficiently without further digging.

Otherwise, compared to Emacs, VIM is magnitudes more easier to configure, mainly thanks to the excellent, thoroughly indexed documentation. Emacs' hooks are the dependency hell and I wouldn't want to dig through them even if given money.

Anything but Vim, please (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32159608)

If all I had was a text terminal... maybe. But I don't know of anything that Vim does that I can't do quicker in Open Office. Can someone allay my ignorance as to the virtues of Vim over anything but Emacs?

Re:Anything but Vim, please (1)

Nursie (632944) | more than 4 years ago | (#32159800)

Please tell me you're not using OO.o for writing code!

Re:Anything but Vim, please (1)

h4rr4r (612664) | more than 4 years ago | (#32159802)

regex.
Not having to waste time with the mouse.

Re:Anything but Vim, please (2, Informative)

blair1q (305137) | more than 4 years ago | (#32160140)

But if you really must waste time with a mouse to feel superior, you can just run vim as gvim.

Re:Anything but Vim, please (1)

Tetsujin (103070) | more than 4 years ago | (#32159862)

If all I had was a text terminal... maybe. But I don't know of anything that Vim does that I can't do quicker in Open Office. Can someone allay my ignorance as to the virtues of Vim over anything but Emacs?

I can't imagine editing code in Open Office would be at all enjoyable, personally...

VI isn't exactly my cup of tea, either, and I can appreciate people's complaints about Emacs - but I'd hate to edit code in something that didn't simplify the process of formatting code, and which didn't let me adjust the rules for how code should be formatted...

Re:Anything but Vim, please (1)

joggle (594025) | more than 4 years ago | (#32159950)

It's primarily best as a code editor. It has syntax highlighting support for many different language, probably more than any other text editor other than Emacs.

It is extremely fast at doing search and replaces, both of which can be quite complicated (although using a bastardized version of RegEx that requires a lot of backslashes to do anything complicated). It also provides a ridiculous amount of control over cursor position via keyboard commands which can certainly increase your efficiency at editing code (since you rarely need to take your hands off the keyboard to move the mouse).

One ideal use of vi is to quickly write some similar code (such as copy constructors). Simply write the initialization of variables once, copy this from the default constructor to the copy constructor and equal operator, do a couple of search and replaces then you're done. I can't imagine doing it quicker in any other editor.

The only feature it lacks that an editor like Visual Studio provides is refactoring. You can effectively do it for a single file, but across multiple files it wouldn't be as easy as it would be using Visual Studio. It also doesn't provide good support for auto-completion (yes, there are plugins but I've never seen one that works as well as the one in Visual Studio).

Re:Anything but Vim, please (1)

value_added (719364) | more than 4 years ago | (#32160502)

... using a bastardized version of RegEx that requires a lot of backslashes to do anything complicated

Actually, that's not correct. My terminology and details may be a bit off, but Vim (along with ed, sed, grep, awk, etc.) uses Basic Regular expressions. Extended regular expressions (along the lines of egrep, etc.) came later. Those did away with most of the escaping that you're referring to. Then, of course, there's Perl (and Perl-compatible) regular expressions. They make everything else look unwieldly by comparision. Vim does have offer integration with Perl (a compile-time option) so that's your answer if you find Vim too old fashioned.

It also provides a ridiculous amount of control over cursor position via keyboard commands which can certainly increase your efficiency at editing code (since you rarely need to take your hands off the keyboard to move the mouse).

And once you've discovered that, you'll never quite get used to the fact that everything else is positively clumsy, awkward, and inefficient.

Re:Anything but Vim, please (1)

tempest69 (572798) | more than 4 years ago | (#32160034)

sure.. lets say that you need to find and replace some text
you can go
esc:%s/old/new/g
of course you can do that in OO without stretching the neurons.
but let's say you need to be trickier and only remove it from the end of line
esc:%s/old\n/new/
sure you can figure that out too..
ok how about find numbers at the end of the line and you want them on a new line as well
esc%s:/([0-9]*)\n/$1\nEndLineNumber was: $1\n/
ok now that is getting a bit odd in OO. now Vi can go quite a bit further before you throw up your hands and run to perl.
when I want to delete something of known length I can type in 12x to remove 12 characters.

And really my favorite piece is the syntax highlighting file. I make mistakes plenty of them.. when I'm bleary working on something put off far too long. I have a highlighting file that notifies me that I typed:
retrun result;
or
if (x=7) {do something silly;}
vector (vector (int)) myIntMatrix; // [parens standing in for angle braces] )) and ) ) are deeply different here.

just my .02

Storm

Re:Anything but Vim, please (1)

Hatta (162192) | more than 4 years ago | (#32160064)

You can hardly do anything in OpenOffice without using the mouse. You can do everything in Vim without taking your hands off the keyboard.

Re:Anything but Vim, please (1)

fl!ptop (902193) | more than 4 years ago | (#32160070)

Can someone allay my ignorance as to the virtues of Vim over anything but Emacs?

:%s/ChangeAllInstancesOfThis/ToThat/g

And I didn't need to use the mouse or a Function key. Plus I get the power of a regex to boot. It's by far my most favorite feature of Vim.

Re:Anything but Vim, please (3, Informative)

Chad Birch (1222564) | more than 4 years ago | (#32160172)

Well, I'm not sure that I believe that you actually use OpenOffice to edit code, but here's my standard example of something I can do much faster in vim than people can in other editors:

Imagine you have the following line of code:

$welcome_message = "Welcome to my site!"; // message displayed at the top of the main page

How would you go about changing the welcome message?

Most people I know would use a combination of Home, End, Backspace, Shift, and the arrow keys to select or delete the string, and then type in a new welcome message. Some would reach over to grab the mouse and select the string, then type over it. In vim, I just need to get my cursor between the quote marks (and there are many ways to do this, personally I'd probably use a quick find and then a couple pushes of w or e). Once anywhere inside the quotes, I just type ci" (a 3-part command, change inside ") and it erases everything inside the quotes and puts me into insert mode. I can easily do this faster than your hand can even get to your mouse.

Yes, vim is hard to learn, and it's frustrating for quite a while. But once you start actually understanding the "language" of its commands and how they fit together, you'll wonder how you ever used anything else.

Re:Anything but Vim, please (2, Informative)

u17 (1730558) | more than 4 years ago | (#32160498)

Wow, that's useful. I normally do: f"ldt" (find", l: move one right, delete 'till ")

um... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32159698)

Who cares? Emacs is far superior anyways due to its superior customization. And if you really like vim's editing paradigm, theres always VIPER mode (VI Plan for Emacs Rescue) which emulates all the VI keybinds.

Re:um... (2, Insightful)

ThePhilips (752041) | more than 4 years ago | (#32160530)

Who cares? Emacs is far superior anyways due to its superior customization.

Yeah... If only mere mortals could do it. Or the mythical sages of Emacs configuration left their caves once and enlightened us all.

The simple truth is that yes, Emacs is much much much more customizable. But the extreme customize-ability makes it impossible for normal users to customize anything without breaking something else. I yet to see a single Emacs user who has written the .init.el her/himself - not grabbed some decade old copy off the net.

Yes, but... (2, Funny)

FreeFlyer (1744362) | more than 4 years ago | (#32159710)

Can it help me find the holy-grail?

Re:Yes, but... (1)

Yvan256 (722131) | more than 4 years ago | (#32160060)

Ni [wikipedia.org] !

Re:Yes, but... (1)

blair1q (305137) | more than 4 years ago | (#32160170)

Yes. Once you have vim, you can install cscope, and there you are.

Re:Yes, but... (1)

aix tom (902140) | more than 4 years ago | (#32160190)

Yes:
/holy-grail

Re:Yes, but... (1, Informative)

Anomalyst (742352) | more than 4 years ago | (#32160386)

try

/holy\-grail

for proper results

Nano (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32159726)

Nano. If I need or want anything else I use a graphical editor.

For those wondering how to stop reading (0)

Anonymous Coward | more than 4 years ago | (#32159746)

A first-time reader might have trouble figuring out how to stop reading the book. You just type escape, colon, q, exclamation point, click your heels three times and say "There's no place like the command prompt."

Re:For those wondering how to stop reading (1)

clone53421 (1310749) | more than 4 years ago | (#32159808)

Pff. I never do that; it’s much easier to just flip the (light)switch.

Re:For those wondering how to stop reading (1)

Kell Bengal (711123) | more than 4 years ago | (#32159844)

Easy!

"Steep" learning curve (4, Interesting)

Dracker (1323355) | more than 4 years ago | (#32159782)

This is one of my pet peeves.

A steep learning curve refers to something that is quickly learned, as the curve that represents knowledge over time would indeed be steep in that case.

Something difficult would have a shallow learning curve, not a steep one.

Re:"Steep" learning curve (5, Insightful)

Tetsujin (103070) | more than 4 years ago | (#32159890)

This is one of my pet peeves.

A steep learning curve refers to something that is quickly learned, as the curve that represents knowledge over time would indeed be steep in that case.

Something difficult would have a shallow learning curve, not a steep one.

I think usually when people talk about learning curves, the horizontal axis represents knowledge and the vertical axis is your investment to acquire that knowledge.

Is there some established convention that contradicts this?

Re:"Steep" learning curve (4, Informative)

Clueless Moron (548336) | more than 4 years ago | (#32160186)

This is one of my pet peeves.

A steep learning curve refers to something that is quickly learned, as the curve that represents knowledge over time would indeed be steep in that case.

Something difficult would have a shallow learning curve, not a steep one.

I think usually when people talk about learning curves, the horizontal axis represents knowledge and the vertical axis is your investment to acquire that knowledge.

Is there some established convention that contradicts this?

The problem is that in mathematics, the independent variable normally goes on the X axis (horizontal). In the case of learning, "effort" is the independent variable since "knowledge acquired" depends on "effort" and not the other way around. By that model a steep learning curve is one where a little bit of effort gains you a lot of knowledge. Unfortunately this doesn't match the classic usage of the phrase.

And that's why I don't use that phrase. Instead I say things like "python has a gentle learning curve" or "emacs has a tough learning curve"

Re:"Steep" learning curve (1)

lahvak (69490) | more than 4 years ago | (#32160340)

The problem is that in mathematics, the independent variable normally goes on the X axis (horizontal). In the case of learning, "effort" is the independent variable since "knowledge acquired" depends on "effort" and not the other way around.

Hm, I disagree with that. Assuming that knowledge acquired is a one-to-one function of effort, it does not matter which of the variables is dependent and which is independent. I think more common question is going to be "how much effort do I need to acquire certain knowledge?", rather than "how much knowledge do I acquire with given effort?".

Re:"Steep" learning curve (3, Funny)

clone53421 (1310749) | more than 4 years ago | (#32160216)

He’s assuming that the horizontal axis is Time, which would be pretty typical for most graphs. Not for learning curves, though.

Re:"Steep" learning curve (1)

Garble Snarky (715674) | more than 4 years ago | (#32160294)

Yes, the convention of placing independent variables on the horizontal axis and dependent variables on the vertical axis. Though I think the expressive use of "steep" to mean "requiring effort" justifies ignoring that convention.

Re:"Steep" learning curve (1)

tnordloh (462939) | more than 4 years ago | (#32159924)

The knowledge it takes to get you up and running in a VIM editor can easily fit on a post-it note. After that, you can learn at whatever pace you want. In my opinion, the learning curve is whatever you choose it to be; also, who would buy a book on VIM, have we not heard of google?

Re:"Steep" learning curve (1)

blair1q (305137) | more than 4 years ago | (#32160266)

my latest vim post-it note is at eye level:

s symbol
g definition
d called by this fn
t text string
e egrep pattern
f file
i including this file

extra credit for anyone guessing what it's a list of

Re:"Steep" learning curve (1)

Idiomatick (976696) | more than 4 years ago | (#32159976)

Climbing a steep mountain doesn't mean you go upwards super fast. It means that it is tiring and laborious. So rather than thinking that the curve is knowledge_rate x time. Think effort x total_knowledge.

Re:"Steep" learning curve (1)

Moridineas (213502) | more than 4 years ago | (#32160038)

You're right about the technical / original intent of the phrase, but it's clearly entered the colloquial more literally (you have a steep [ie, difficult] path ahead of you to learn).

Think of it this way...if you have a revolutionary new product that's very easy to learn to use, would you advertise it as having a "steep learning curve" and expect people to think that's a good thing?

This phrase, like many others (think "begging the question") due to the literal meanings of the words has a different meaning from the original. Good luck trying to change it...

Re:"Steep" learning curve (1)

boneclinkz (1284458) | more than 4 years ago | (#32160080)

This is one of my pet peeves. A steep learning curve refers to something that is quickly learned, as the curve that represents knowledge over time would indeed be steep in that case. Something difficult would have a shallow learning curve, not a steep one.

An exponential learning curve.

Re:"Steep" learning curve (1)

adonoman (624929) | more than 4 years ago | (#32160192)

Think of the X axis as the amount of stuff you can do, and the Y axis as the amount of time/effort involved in learning. Then for VIM you end up getting something roughly like a square root graph.

Re:"Steep" learning curve (1)

blair1q (305137) | more than 4 years ago | (#32160220)

Wrong-o. Something with a steep learning curve is somthing that has a lot to be learned in a short period of time in order to put it into productive use.

It's not about how easy it is to learn the stuff, it's about how much stuff there is and how much of it you need up-front.

Re:"Steep" learning curve (0)

Anonymous Coward | more than 4 years ago | (#32160324)

Only ever been interested in one hack... (0)

Anonymous Coward | more than 4 years ago | (#32159846)

This is probably the only "hack" you need: http://www.vim.org/scripts/script.php?script_id=300 ;-)

Get the following volumes too: (5, Funny)

Ancient_Hacker (751168) | more than 4 years ago | (#32159850)

Get the followup volumes too:

Noise cancelling algorithm design using sh. ( Shhhhhh... )

Real-time traffic control with bash.

Time-domain-reflectometry made easy, with sed.

GPS satellite tracking with tr.

Build a species database with Python. ... and many more ...

Re:Get the following volumes too: (1)

khedron the jester (888418) | more than 4 years ago | (#32160232)

Go on... give him some mod points!

Vim most definitely can't "do everything" (1)

melted (227442) | more than 4 years ago | (#32159904)

Case in point: I want it to show me a vertical line at 80 chars, like TextMate or GEdit. Not even GVim can do this. :-)

Re:Vim most definitely can't "do everything" (0)

Anonymous Coward | more than 4 years ago | (#32160116)

I was under the impression that peoples using vim should be able tu submit a patch for that long ago, but there isn't anything along that line yet. The closest you can get for now is by highlithing text after the 80s characters on each line (which somewhat does the job)

Re:Vim most definitely can't "do everything" (1)

lahvak (69490) | more than 4 years ago | (#32160152)

Well, you could create a syntax rule that would highlight the 80th character on each line, or the first 80 characters, or the 81 and higher characters...

The problem is, what is a character?

Re:Vim most definitely can't "do everything" (1)

Bugamn (1769722) | more than 4 years ago | (#32160246)

What do you mean by "vertical line at 80 chars"? And why are you sure that VIm can't do it?

Re:Vim most definitely can't "do everything" (1)

Obfuscant (592200) | more than 4 years ago | (#32160268)

Case in point: I want it to show me a vertical line at 80 chars, like TextMate or GEdit. Not even GVim can do this. :-)

My copy of vim does. It's called "the right edge of the window". That's why running an xterm in 80x24 is good.

My main peeve with vim is when it goes into "recording mode" or whatever that nonsense is, when I try to ":q" and hit something by mistake and the screen splits. I still don't know what I did wrong. And that vim always wants to go back to the last place in the file you edited, even if you edited the file ten years ago and really want to start at the top. The only way I found around that one is to make the .viminfo file chmod 000 so it can't save status.

Re:Vim most definitely can't "do everything" (1, Informative)

Anonymous Coward | more than 4 years ago | (#32160466)

Not exactly what you're looking for, but it solves the same problem:

http://stackoverflow.com/questions/235439/vim-80-column-layout-concerns#235970

highlight OverLength ctermbg=red ctermfg=white guibg=#592929
match OverLength /\%81v.\+/

First Step in hacking VIM (0)

Anonymous Coward | more than 4 years ago | (#32159952)

Use Emacs to open the .vimrc file :)

VIM totality (1)

fluffernutter (1411889) | more than 4 years ago | (#32159958)

I know about 5% of VIM and that does everything I need in a text editor. I always wonder why the other 95% was created and who the heck uses it.

Re:VIM totality (1)

blair1q (305137) | more than 4 years ago | (#32160308)

ppl w lk tpg les

/ESC/ /ESC/ :wq! (1)

stakovahflow (1660677) | more than 4 years ago | (#32160490)

"/ESC/ /ESC/ :wq!" was the first thing I ever learned in vi/vim back 11 years or so ago...

I tried using nano, pico, emacs, etc.

I just couldn't get over the lack of real-estate (standard terminal).

A lot of folks swear at VI/VIM...
I, for one, swear by it...

Now, all I have to do is convince the wife that ANOTHER "computer" book is necessary...

Cheers, guys!

--Stak

Rating inflation (4, Interesting)

jmilne (121521) | more than 4 years ago | (#32160524)

I read the review before I really noticed the rating. How does this book earn an 8 for a rating? The reviewer states that Chapters 1 was unnecessary, and has some harsh things to say about several other areas:

Chapter 3 is about text navigation. Sadly, the book doesn't go into as much detail on movement commands as I would've liked.

I had high hopes for Chapter 6 and 7, which deal with Vim scripting, but I was largely disappointed.

If you're looking for any advancing information on writing your own functions in Vim script, you're mostly out of luck here.

Overall, stylistically the book is a bit dry and humorless

I do feel the book should've gone into more detail in many areas. At 244 pages, the book is short and gives a rather shallow view of many of Vim's features.

There's nothing in this book you won't find in Vim's built-in documentation

At best, it seems like this would earn a 5 rating.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?