Slashdot Mirror
Hacking Vim 7.2
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.
Hacking Vim 7.2
author
Kim Schulz
pages
244
publisher
Packt Publishing
rating
8
reviewer
briancarper
ISBN
1849510504
summary
Customizing and scripting Vim 7.2
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.
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.
but does it tell you how to pronounce "Vim"??? (first post?)
"It takes considerable knowledge just to realize the extent of your own ignorance." - Thomas Sowell
Use EMACS
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:
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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.
Can it help me find the holy-grail?
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.)
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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.
... you finish your subject in the comment body
for fun and productivity
That's two counts of *hacking* right there. As vim wasn't originally designed for either use.
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.
Please tell me you're not using OO.o for writing code!
regex.
Not having to waste time with the mouse.
Pff. I never do that; it’s much easier to just flip the (light)switch.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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.
Welcome to the Panopticon. Used to be a prison, now it's your home.
up
Bow-ties are cool.
Easy!
Scientists point out problems, engineers fix them
altslashdot.org: The future of slashdot.
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 ...
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...
Bow-ties are cool.
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.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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?
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. :-)
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).
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.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Definition of hack, Jargon File
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;
just my .02
Storm
I’ll see your Jargon File link and raise you three more.
http://catb.org/jargon/html/N/neat-hack.html, sense 1
http://catb.org/jargon/html/H/hacker.html, senses 1 & 7
and http://catb.org/jargon/html/meaning-of-hack.html.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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.
You can hardly do anything in OpenOffice without using the mouse. You can do everything in Vim without taking your hands off the keyboard.
Give me Classic Slashdot or give me death!
:%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.
When you recognize love in another and realize how precious it is, everything else seems so insignificant.
But if you really must waste time with a mouse to feel superior, you can just run vim as gvim.
Unlike you, I wasn’t trying to be funny.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
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:
// message displayed at the top of the main page
Imagine you have the following line of code:
$welcome_message = "Welcome to my site!";
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.
Sturgeon was an optimist.
Add :filetype off to your .vimrc. That should disable most of the cruft.
Last bit is this (sorry for ma poor Engrish).
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.)
All hope abandon ye who enter here.
"/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
Holy happy hippy crap!
Wow, that's useful. I normally do: f"ldt" (find", l: move one right, delete 'till ")
... 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.
I suspect most users of Visual Studio don't add significant hacks (other than installing third-party plugins like Resharper)
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.
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.
All hope abandon ye who enter here.
Perhaps we should define "old machine". To some people, my dual core Opteron on an Asus SK8V clocked at 2.2 Ghz might be an old machine. To other people, you might have to go all the way back to a socket 7 to be "old". Yet others might argue, and insist that it isn't "old" unless you're running a 286. *shrug* I don't know what you mean by "older machine"!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
While reading the review of the book, I thought the reviewer's comment about the history of Vim being unnecessary to be wrong. Having used Vim on various systems including RHEL, Fedora, Mac OS X, Windows (gvim), and BSD there are some differences that catch unaware users off guard. Most Linux operating systems will install Vi as a standard editor and add an alias for Vim to use Vi. This is seems all well and good, however Vi has some pain points in particular the inability to backspace / delete characters on the current line. Anyhow, I'm not sure ignorance is the best policy especially as there are so many variations out there on different OSes.
Vi was made for productivity. It was built to help you edit text efficiently over low bandwidth connections (specifically Bill Joy's 300 baud modem). Since Vim has more features designed for convenience, you could argue that it was made so you could be even more productive when editing text.
Funnily enough, F1 works in VIM as expected: open the help. And the :qa! tip is right there close to the top (in my VIM is on 4th line).
All hope abandon ye who enter here.
Just thought I would mention it, vimperator is the best firefox plugin of all time.
Brings the glory if VIM to firefox.
Seems like just yesterday that X in the statement "'[X] Can Do Everything' but configuring it to do so is sometimes daunting." would have been Emacs. Further evidence of the decline of civilization ... what's next- "'a GUI Can Do Everything' but configuring it to do so is sometimes daunting?"
Configuring your editor is something you pretty much do once then forget about. The time wasted by not configuring your editor is ongoing.
We hope your rules and wisdom choke you / Now we are one in everlasting peace
Put \v at the beginning of your regex and you won't need as many backslashes. This is the so-called "very magic" mode. You can even switch back and forth between magic and non-magic in the same regex via \v and \V.
For example, most censors at the FCC use Vim to generate the BEEPs over forbidden words. For everything else, you there is Emacs.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
I remember seeing a vim hack once, a few years back, where someone used the stdin/paste to make vim animate a picture of ASCII art. :(
Can't find the link, though
Did you know that "FTW" ("for the win") is a direct translation of "Sieg Heil"?
Or the mythical sages of Emacs configuration left their caves once and enlightened us all.
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.
It's probably just me, but these statements seem contradictory.
Seriously, emacs users are actually a really helpful bunch, check out the emacs wiki for instance. Or consider the amount of effort that's gone into making the customization system (M-x customize) easy for both end users to use and emacs-lisp developers to incorporate into their extensions. Or the quality (and price!) of the Emacs manual, Introduction to Programming in Emacs Lisp, or Emacs Lisp Reference Manual.
Emacs users might be perceived as elitist or something, but the feeling I've always had is that it's a community that strives to be welcoming and not holier-than-thou.
My main one is using this plugin: http://www.viemu.com/ :)
Cool, that's a new one for me. Thanks!
We hope your rules and wisdom choke you / Now we are one in everlasting peace
Have you tried it? I did.
I once wanted to make sure that Emacs always indents with tab, but even cc-mode developers couldn't help me. I have tried to unroll the nested hooks which are responsible for the handling of keys where the broken indentation was happening but at the IIRC 7th level of nesting I have simply given up.
That's [*BEEP*]ing unmanageable. I have a full-time job already. And configuring Emacs is a full time occupation, a luxury I can't afford. Nor I wanted to become dependent on something so unmanageable for the crucial task of source code editing, which takes about 90% of my working time.
No, I do not like modes of VIM. In fact I hate them. Yet I learned to live with them. Because I still could make out of VIM precisely the editor I needed - within few days - without wasting precious time (I spent two weeks configuring Emacs) hacking through endless megabytes of the unmaintainable elisp mess.
All hope abandon ye who enter here.
Honestly, Emacs does have a lot of stuff, but it's pretty much all load-on-demand these days. Jokes aside, a basic startup can be pretty darn quick:
% time emacs -nw -Q --kill
real 0m0.089s
user 0m0.067s
sys 0m0.012s
If I force it to load CC mode with a ~4kloc C++ file to edit, that rises to about 0.185s real. More importantly I only pay the extra delay the first time. Things are pretty much instant after that. If that's not enough, I can amortize the cost over a persistent session running for weeks at a time with multiple clients attached from different terminals.
Oh really? And here I thought it was designed by touch typists who needed powerful editing features, and were willing to put some effort into achieving it.
Ah well, guess I'm autistic then.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Vi - designed and used by people far off into the distance on the autistic spectrum.
Aka Slashdotters.
Emacs users might be perceived as elitist or something [...]
I have learned VIM already. It's too late.
But actually my impression of an Emacs user is far from "elitist." It's more like a "helpless baby."
I have worked in company where 90% of people used Emacs. And literally nobody could customize it. They had ~120K init.el from somebody else, it got copied all over the company, everybody used and nobody had a clue what was in it.
I also knew real pro Emacs user who knew pretty much all shortcuts and modes of the Emacs. But he also hardly ever tried to configure it: he tried it in past, failed and learned to live with the defaults instead.
In my past two (failed) attempts to learn Emacs, I also found out that even Emacs mode developers are not always aware what's going on inside of it and how to change it: modes are layered on top of each other and changing something in one mode might break inadvertently other modes in a non-obvious fashion.
All hope abandon ye who enter here.
Obviously your problem is that your machine has more than 8 MB of RAM in it; otherwise it'd be running fine just like its name says.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The review pans the inclusion of a history chapter in the book. I haven't seen the book's history chapter, so maybe it is not a good one. However, I can say that knowing the history of vi helps enormously if you're trying to "hack" it so I think such a chapter is needed.
By knowing the history of vi you will know that it was built on top of a line editor, ex. That helps the beginner understand why vi is a modal editor and why some commands are available both as ex commands (with a colon preceding them) and as normal mode commands. One of the powerful things about all those ex mode commands is that they are easy to script. You can feed a bunch of ex commands into vim from standard input, thus completely scripting an editing session without learning a bizarre scripting language. (You do however have to learn bizarre ex commands :) This is an easy workaround for some Unix conundrums--that you can't, for example, easily stick text onto the beginning of a file from the command line. I've got shell scripts that do this. (One could also use ed, but again, it helps to know the history of vi to know this stuff.)
Knowing the history also explains other vim oddities. For search, vi uses patterns under which some characters, like curly braces, only have special meaning if they are escaped. When you understand that old Unix utilities used regular expressions that are like this, and that the vi patterns thus resemble the patterns that you use with grep (not egrep) or sed, this makes more sense. It also makes all the vim "magic" settings make more sense.
Also, understanding the history of Unix made it easier for me to understand vim's limitations. For awhile I tried to learn vim script so that I could write scripts that would automatically generate certain text for me. Maybe this would be easy with, say, emacs, but vim script just seemed painful to me--and then it would only work with vim. With time I learned that vi fits in with the Unix toolbox model. Rather than use your editor to generate boilerplate text, it's very easy to generate that sort of thing in a shell script or using m4. Then just load it up into the editor. Vim also uses some external programs, such as ctags.
Unix is a big grab bag of tools that have a long history. I have always found that knowing the history of these tools and where they came from and how they were meant to be used together is enormously helpful.
Penny - plain text accounting
"Vim Can Do Everything' but configuring it to do so is sometimes daunting."
That was one argument people made in school for using VI instead of EMACS......and they were right.
Vim has about twice as many options as vi did back when I ran it on dumb terminals on a Vax 11/780. My laptop CPU is about 3000 times as fast (per core), and the 4GB RAM is 4x as large as the disk drives on my VAX, or 1000 times as large as the RAM. And yes, running it on top of WinXP is probably tougher than running on top of X Windows, but X ran just fine on a Sun3/60 or 25 MHz 386. (I suppose I should pay more attention and turn off random modes like +farsi, though :-)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
That method is fine too and it works in plain old vi. You only save one keystroke really: instead of your f"ldt" (i.e. 6 keystrokes), you type f"ci" (i.e. 5 keystrokes) :D.
...
:h object
However, ci" (or ci{ etc) are most useful when you are inside the text object. Then you don't have to find or move to the boundaries of the text object to modify its contents. This is even more useful for XML tags, e.g.
<tag>
line 1
line 2
line 3
</tag>
If your cursor is in line 1 or line 2 etc, you can type dit (delete innner tag) and delete everything between <tag> and </tag>
similarly
if (condition) {
line 1
line 2
}
if your cursor is anywhere in the {} block (line1, 2 etc) the command ci{ will delete all lines between { and } and put you in insert mode. Very useful.
For a complete list of all supported text objects type
As the island of our knowledge grows, so does the shore of our ignorance.
Yes. Yes you are.
So I assume you use notepad?
^:q!
The mnemonic is "ESCape this COLON thingy - Quit and do !RETurn
Seriously, though, emacs vs. vi jokes aside, either one is a decent editor, and pretty much nothing else comes close.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
i think you two doubled my productivity in vim again ...
Code editor? Excellent. Let's make a python editor out of it. [1]
Syntax coloring? Check. Proper indentation? Check. Well, almost (backspacing over automatically inserted spaces doesn't seem to remove them in one go). Tab completion? Ch... hmmm. Omni completion is almost there. Almost, because it opens a scratch buffer with documentation. While this is understandable when running in terminal, it looks rather bad in GUI. It also doesn't seem[2] to be aware of local modules. There's some basic support for inspection, in the form of taglist plugin, but - again - separate buffer. And if you want something more IDE-like, ie. integrated debugger - good luck with that.
Don't get me wrong, I like VIM, and it's a fine editor. It's a good, ubiquitous tool. I'm just not exactly convinced that it's a decent programming editor. I've tried to use it as such, with various amount of success. Things probably look different for C, though.
[1] yes, I've read http://blog.dispatched.ch/2009/05/24/vim-as-python-ide/
[2] perhaps it can do this after flipping some option, but I haven't looked at it closer yet.
-- we're here you're not
I have worked in company where 90% of people used Emacs. And literally nobody could customize it. They had ~120K init.el from somebody else, it got copied all over the company, everybody used and nobody had a clue what was in it.
I also knew real pro Emacs user who knew pretty much all shortcuts and modes of the Emacs. But he also hardly ever tried to configure it: he tried it in past, failed and learned to live with the defaults instead.
With respect, I'm not sure either of these issues are the fault of the software.
For instance, the default Apache httpd.conf reads:
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
I suspect that a similar warning may have been missing from the init.el that was being passed around.
Of course, emacs-lisp doesn't look much like C (or a language whose syntax derived from C), so there's certainly some getting over the parenthesis and function-first syntax. After that hurdle (and a bit of understanding what a symbol is and how to quote a list), it's just a matter of looking up unfamiliar functions (online, with C-h f), isn't it?
That's in no small part because Visual Studio tries its level best to avoid any sort of sane portability of user customization settings. It's nominally possible to export and import some settings these days, but it's such a PITA that even experienced VS users I know of mostly don't bother.
Thanks! I will use that feature a lot I'm sure.
A minute of customisation of a tool that you use every day can save a huge amount of time. I have a huge blob of vim script that I copy to every machine that I use, and it means that I can do some common tasks on one keystroke rather than a dozen or so. Multiplied by the amount of times that I do such things, it's a huge net win.
I am TheRaven on Soylent News
You're right. If you're just using it to touch up config files, then vim isn't for you.
However, if that's all you think vim is good for, then you don't grok vim. Vim is a fully featured IDE that's coded for terseness. It's made to get things done in the quickest way possible - where "quickest" is mostly defined by the fewest keystrokes. Every key on your keyboard is a hotkey, and every key does something different. Chances are you wont be changing every character to the end of your current line very often, but for that time you need to, there's the command in vim "C". Just a capital c. No highlighting the line, cutting it so you can save it in case you need it back with ctrl+x, etc. Just C.
Make sure it's a capital c though, because just "c" will do something entirely different. With vim it's waste not, want not. You don't waste any key on the keyboard. It makes for, once you get past the rough learning curve, an editor that runs with the best (and then some - I would argue that emacs is the only editor that puts up a fight against vim, but that's an argument for another day). I challenge you to find something that a modern day IDE can do that vim can't.
And I'd really recommend this to people starting using vim. The really nice thing about gvim is that it shows the text commands in all (most?) of the menu items. I learned vim by using gvim. When I started using it, I was clicking on the menus for pretty much everything. After a while, I gradually used the keyboard commands more and more.
Now I use vim in a terminal, because then the vim buffer and the clipboard are two different things and I can select and copy text without moving the insert point. This is something that I really miss in all modern editors that I've tried. Under RiscOS, if you selected with the right mouse button instead of the left, it didn't move the insert point, but no one seems to have copied that.
I am TheRaven on Soylent News
But I don't know of anything that Vim does that I can't do quicker in Open Office.
I can only really think of one thing that I do faster in vim than OpenOffice.org: edit text. Not really surprising, considering that vim is a text editor and OO.o is an office suite. I've written three books (total around 1,600 pages), around 200 articles, a few papers, a PhD thesis, an undergraduate dissertation, and over a hundred thousand lines of code in vim, and I can't imagine trying to use OO.o for most of that.
I am TheRaven on Soylent News
Oh, and ZZ also works for exiting vim - some people find this easier to remember.
I am TheRaven on Soylent News
Then why use it in the first place?
Because we like it?
I would spend a few hundred dollars to a tool that will let you do your work without adding work to be able to use the tool.
Or you could invest a little time up front to learn the tool, and then not pay anything. *shrug* It's a matter of priorities. Believe it or not, some people's priorities aren't the same as yours. Shocking, isn't it?
Vi and vim are not the same thing. Vi is part of the Standard UNIX Specification and is the editor that you are guaranteed to find on any UNIX system. Knowing it is important for disaster recovery, but not much else. Vim is a powerful modern editor designed to be mostly compatible with vi.
I am TheRaven on Soylent News
It doesn't give me RSI from all the chording.
No, seriously, that's basically the only reason I switched from Emacs to Vim (although Vim's much faster startup time is also a real boon).
How do I get vim onto my Motorola Droid?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
I have no idea what version of emacs you tried to configure, but I have mine configured to use tabs only, and it was definitely not a hassle. It took me a few days, yes, but now it works exactly how I want it to.
If you ever give it another whirl, try (tab-width 4) and (c-basic-offset 4). This will force emacs to use tabs for all indentation.
Sure, configuration in lisp is certainly a bit harder, but it is also way more flexible. You can also configure emacs with the built-in configuration editor, too, if you like handy documentation with your settings.
OO won't run on my M-Droid. Vim might. Especially since all I need is Notepad functionality (e.g. text entry and find ability ).
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
There are many people who have "grown up" with those tools, so to speak, and are extremely good at them because they know all ins and outs, and even the more esoteric operations are already on muscle memory level. This isn't true just of Vim, but many other pieces of mature software, and not just on Unix, but elsewhere as well. E.g. I grew up on DOS and NC, and can't live without this thing in Windows even today.
> 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.
*cough* Like hex-editing Notepad++ to support 6 pt fonts ... (faster then building from source :)
Yeah, I realize I could put in a little effort and get much further, but I've already wasted more time just in this session than I could possibly gain back in the next the years by knowing VI inside and out.
And therein lies the crux of your problem. You're simply not a serious programmer.
Think of Vim as a mainframe: for those that require heavy computing power the investment pays for itself practically the moment you turn it on, but for a regular Joe a mainframe is nothing but an insanely expensive computer that you can't even use to browse Facebook on.
I don't recommend mainframes to regular Joes looking to browse the web, I don't recommend Hasselblads to grandmas looking to photograph their grandchildren, and I don't recommend Vim to people that need to make slight changes in a plaintext file only sporadically. But that doesn't mean they don't have a market out there.
No problem is insoluble in all conceivable circumstances.
So y'all are saying I should learn more than "i" for insert and arrow keys and backspace for everything else?
For starters: vim comes with an optional GUI as well. So it is not just a command line editor. In fact the GUI version is pretty neat.
And secondly Vim just does more. At least more then Eclipse or Net beans does in the edit department. It might not compete against SlickEdit without tons of plug-ins but then a 3+ platform licence cost $649.00. Note that I have use Vim on 5 different platforms - one for which SlickEdit is not even available.
:Ni!
Here's why:
1. Vim or vi is on pretty much every UNIX or UNIX-like system - therefore if your sysadmining a number of different UNIX flavours, vi is a common factor on them all meaning the way you edit files is the same.
2. It doesn't use any control keys for navigation - therefore no messing about getting keymaps and emulations right, as long as you have the standard alphanumeric and punctuation characters on a keyboard, you can do any editing you need in it.
3. Your .vimrc config file should be transportable across many flavours of vi - so you can quickly install your favourite shortcuts, macros and syntax highlighting.
Can I just also make a point that this is *ONLY* about familiarity with a particular application and nothing more. Yesterday, for example, it took me a couple of minutes to work out how to print a document in Office 2007 on my missus' PC when I only use OpenOffice (on XP and Linux) - yet I'm a demon editing in vi and even install it on XP because I can edit much faster in that than in Notepad or any other GUI-based Linux/Windows text editor.
Gentoo Linux - another day, another USE flag.
I use Vim every day, and I still don't see how anything which requires manually counting lines on the screen prior to typing a command is supposed to be faster than something which allows lines / characters / words to be highlighted visually prior to typing a command.
-- 'The' Lord and Master Bitman On High, Master Of All
I don't think I'll ever understand people who claim that vim has good / extensive help.
VIM has perhaps the absolute worst help system I've ever come across. It's pretty much impossible to find the answer to anything unless you already know the exact command you're trying to find (and very often the exact misname for that command, since so many keywords have multiple meanings, and help just jumps to the first one)
VIM's help is utterly worthless, and shouldn't even be mentioned in a discussion of vim.
-- 'The' Lord and Master Bitman On High, Master Of All
If I had mod points I would give you + for educational! You taught me something new today. Thanks!
For years, if not decades there have been better and easier tools for anything people use VI/VIM/EMACS/Sundry CLI utilities for (mostly).
I think it happens because professors push these free as in beer tools on students (rightly) for their education, the students get used to them, they get an unjustified sense of pride from learning to use something that *looks* scary and then they are too lazy to learn new things.
A few years ago I almost got my head put on a pike in the ubuntuforums by suggesting that Ubuntu, keeping with its mission of making linux user friendly, remove VI from a default install.
Desktop users will never miss it. Network people looking to quickly touch up config files could be redirected to simplier CLI editors for the job like "nice editor/NE editor" and programmers who STILL develop in a pure CLI environment could download it easily.
IMHO there is a streak of OCD in the tech field and the VI thing is just one of them.
"I hate to ruin..."
Wow! a meagre 218-word paragraph to define "consistency".
Huh? "consistency" is not at all what I just described.
I was making a point about how it's possible for software to have really great facilities to help you learn how to use it - but still be a complicated piece of software to learn.
It's really not very much text. If it's "tl;dr" for you, then just take a fucking hike.
Bow-ties are cool.
I'm a 20 year programmer, I've worked on it just about daily in C, C++, Java and a few others. I find that if I'm typing at my limit then I'm not thinking enough and probably messing something up and putting out WAY too much code for others to maintain.
I spend more time reducing the amount of code "Faster" typests put out.
I do know programmers who use vi and have used Eclipse as well. They generally call it a wash--although I did have one guy say something that kind of made sense--he had gotten so used to the way eclipse code-completes and brings up documentation mid-line at a keystroke that he had forgotten how to code without it, so he uses vi to force him to work harder and remember all that stuff. That sort of made sense to me I guess, although I'd just install eclipse myself.