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
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.
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.
... you have to hack your text editor
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.
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."
for fun and productivity
That's two counts of *hacking* right there. As vim wasn't originally designed for either use.
Kim Kimberley. Wasn't she the detective in the Level 9 adventure Snowball?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
up
Bow-ties are cool.
This is probably the only "hack" you need: http://www.vim.org/scripts/script.php?script_id=300 ;-)
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.
We all know EMACS is a great OS, but what it really needs is a text editor.
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).
Use Emacs to open the .vimrc file :)
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.
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.
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.
... 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.
"/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.
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.
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.
Interesting that this book is not available as and eBook.
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.
import antigravity
import soul
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?"
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.
All 250+ pages of it: http://www.eandem.co.uk/mrw/vim/usr_doc/index.html
Read a chapter a day/week. Dive in and out of the doc every now and then to refresh. There's an incredible amount that can be done easily with vim, without having to install a single plugin or script.
Vi - designed and used by people far off into the distance on the autistic spectrum.
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?
fail.
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.
Cool, that's a new one for me. Thanks!
We hope your rules and wisdom choke you / Now we are one in everlasting peace
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.
From the point of view of someone who doesn't remember or want to remember shortcuts, VI is an abomination.
I use VI occasionally when I can't avoid it. You have to know a few commands (:wq, :q!, a, i, x, dd, /) to be able to use it, but at that it is the most annoying system possible.
If possible I use "cat > file" instead.
VIM is supposed to have help, so I gave it a try. Here's my review of VIM
It comes up with a little help screen.
It says a bunch of stuff I don't really want to read--I just want to know how to navigate to a position visible on the screen--something you should be able to do with a mouse.
I see that :help or f1 gives me "on-line help". worth a try.
I hit f1. It splits the screen and gives me a bunch of other help commands. WTF. I'd already be done twice if I had started with notepad!
Wait, it says I can type ":set mouse=a" to get my mouse to work.
Now I'll type in a little bit to see if it works. I know how to do that, it's "i".
I returns "Cannot make changes, 'modifiable' is off.
Screw this, I'm done. :q!
Damn, they did break the one key I knew! :q! ALWAYS quits out. I'll do it again.
There that worked. Crap, so much for this improved VIM functionality, I'll stick with vi in cases of extreme emergency when cat >> file just won't do the job.
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.
The funny thing is that the arguments by the pro-vi guys are just as ridiculous as this.
I do wish all editors had "dd" though.
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?
Thanks! I will use that feature a lot I'm sure.
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
So.....it can't do what Visual Studio does by default? hmmmm I might keeping staying away from an editor that uses :q then.
Let me know if there are vim plugins for VS so that I can reduce the learning curve and i'll reconsider.
2c
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?
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."
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.
Let me know if there are vim plugins for VS so that I can reduce the learning curve and i'll "reconsider."
Let me know about a "professional" that gives more credit to "reduce the learning curve" than to "achieve higher productivity" and I'll show you a moron I certainly won't hire.
He's a guy. A simple google search yielded this:
http://www.schulz.dk/en/blog/
His name is kim schulz, as mentioned on the top of this page.
So y'all are saying I should learn more than "i" for insert and arrow keys and backspace for everything else?
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).
You might know this already, but if you're in the line, you can use fW or Fw. I'm a pretty advanced power user, but was (as usual) blown away when I found this little nugget out. :help f for more info.
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.
Pro's use emacs. Followers use vim.
: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.
If I had mod points I would give you + for educational! You taught me something new today. Thanks!
The object didn't arrive at its destination, it started at its origin.
The client didn't receive the data, the server sent the data.
You are not in Soviet Russia, Soviet Russia surrounds you.
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.
Saying "I'm going to hack vim (or vi)" is like saying "I'm gonna go bolt some rear spoilers onto my horse-drawn plow."
Just let vi die, already. Put a stake in its heart. Constantly Franken-retrofitting it to be slightly less annoying is a complete waste of time when there are 65 billion real text editors available out there, plenty of them FOSS.
"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.