Why, oh why, these #? @! assholes use vi?

I offer the readers of "Habrakhabr" a translation of the article "Why, oh WHY, do those #? @! Nutheads use vi?" by John Beltran de Heredia.

Yes, even if you can't believe it, the vi editor, who saw the light more than thirty years ago (and his younger, only a fifteen-year best clone & a big improvement - vim) has a lot of fans.

No, they are not dinosaurs who do not want to keep up with the times - the vi user community continues to grow: I, who started only two years ago (after ten years of work as a programmer). My friends are switching to vi now. Hell, most vi users haven't even been born when it was written!

Yes, there are specific reasons why the vi / vim editing model is superior to any other. You do not need to be an Unix expert to use vi — it is available for free on almost any existing platform; For most IDEs, there are plugins that allow you to use its features. Let us dispel some misconceptions and consider a couple of examples demonstrating its superiority.

Misconception number 1: modal editing

When confronted with vi or vim for the first time, you experience shock and disgust at having to press "i" in order to start typing. You can not remember which of the buttons "hjkjl" for which direction is responsible. And you have to press "a" to type at the very end of the line. Since you, probably, have already used other editors, and in the input mode the navigation with arrows works, you only use it, switching to command mode only when absolutely necessary. Perhaps you will spend twenty minutes on this, constantly complaining "how, in the name of all that is holy, I must remember what mode the editor is in now!" - and never want to use vi again.

But this is just an absolutely wrong way to use vi. Proper use is not modal. You are always in command mode and enter input mode only for short, "explosive" typing, and then immediately return back to command mode. That is why the problems I-not-remember-in-some-mode does not exist: you do not answer the phone while in input mode, but when you return, you try to remember where you were. You write the code, the phone rings, you return to command mode, and then answer the call. Or return to it when you agree, but you never think of the input mode as the mode in which you usually work.

Let me explain the philosophy behind it.

Commands in vi are designed to be combined: 'd' means "delete", 'e' means "move the cursor to the end of the word", therefore 'de' is a complete command meaning "delete everything from the current cursor position to the next end of the word" (something like Ctrl-Shift-Right, Left, Del in most regular editors).

The first positive consequence of this is that the command '.' repeats the last completed combined editing command (but not the move command). After pressing 'dw', '.' behaves like the "delete from the current cursor position to the next word start" command. You can navigate through the file with all the power of the navigation commands and press '.' wherever you need to remove everything before the next word, very quickly. This feature is incredibly powerful.

And now we got to the input commands. These commands, after performing actions specific to each action, place the editor in input mode, allowing you to type text. So, for these commands, the full text of the command contains all the text you entered between the 'i' (or which input command you used there) and the exit to command mode.

This means that if you typed "iHello [ESC]", which introduces "Hello" at the current cursor position, now '.' - This is a command that enters "Hello" at the current cursor position. And that's it. You can imagine how powerful this opportunity is. "A" moves the cursor to the end of the line and activates input mode. After completing a set by pressing [ESC] you can press '.' anywhere to repeat input at the end of the line.

Another even more impressive example: the 'ce' command, which is a combination of the 'c' and 'e' commands. The 'c'hange command removes the range indicated by the move command that follows it and activates the input mode. Like the 'd' command, but with exit from command mode. The advantage is that the text typed during the next (short) input session is also part of the command. So if you type 'ceHello [ESC]', you replace part of the word from the current cursor position to the end of the word with "Hello", and then the command '.' allow you to repeat this input as many times as necessary.

Move commands can also be much more complex and supplemented with various edit-translate-in-input-commands ('o' - 'create a new line under the current', 'O' - 'create a line above the current', 'S' - "delete everything to the end of the line", etc. they all translate into input mode). Just imagine what editing patterns you can create and repeat with a simple “.”!

Example # 1: Awesome Point Team

Let's look at an example. Suppose you declare three new functions in your header file and now you need to implement them in a module. You copy the following text and paste it into the module file.

All the code starts with this, right? Now it would be nice to remove the semicolon characters and add empty function bodies. With the cursor in the position as in the picture above, you can press "A" to go straight to the input at the end of the line:

Notice the input mode cursor at the end of the line. Now you need to delete ";" using [BACKSPACE] and type "[ENTER] {[ENTER]} [ENTER]" to create an empty function body, as in any other text editor.

Now press the escape key to go into command mode:

And now we need to repeat all this with the remaining two. How to do it? Easy: press 'j' to move the cursor down one line and then '.' To repeat editing (from “A” to [ESC]). If you hit 'jj', you will get the following:

Just 'jj'! The key here is the architecture of the vi commands, along with the fact that [BACKSPACE] is part of editing as usual typing and the fact that editing operations are highly repeatable. Think how many of your daily edits are repeatable? Yeah, I thought so.

Misconception number 2: it's not in regular expressions

Vi / Vim is great at handling regular expressions. All more or less serious text editors support regular expressions - search, replace, and so on, but only vi (from those that I know) can use their complex combinations like "search and replace the second inclusion of" begin "after the line containing" proc ", or what else might come into your head.

So I don't want to downplay the value of regular expressions or the ability of vi / vim to process them. But the real power of vi, a power that you cannot live without after learning how to use it, is the power of the basic text editing model:

One- or two-button commands to move exactly where you need in a line or on the screen.
Commands like 'd' or 'c' which, when combined with the move commands, allow you to directly change a piece of code that interests you with the ability to repeat editing by simply pressing '.'
Hands are always in a comfortable position on the keyboard. Editing is equally comfortable on both PC and laptop.

Example 2: smart ranges

Let's look at the following typical example. This is just a function call embedded in some complex expression:

As you can see, the cursor is at the beginning of the function call. Now imagine that we want to remove it from there and assign it to some local variable. First we need to select a function call, copy and delete it, type the name of the variable, move up one line to declare this variable. Following the usual editing model you would start playing with Ctrl-Right and left / right until you did everything right. But not with vi / vim. The move command '%' allows you to move from the opening bracket (or other grouping character) to the corresponding closing bracket - but if the cursor is not on one of these special characters, vim goes right to the first such character, and then moves the cursor to the corresponding closing symbol. That is, in our case, the cursor will move directly to the closing bracket of the function call!

Knowing that the 'c' command deletes the text throughout the length of the movement following it (and also copies it to the clipboard), we can simply type 'c%' and get the following:

Our function call is copied to the clipboard and we are ready to enter the name of the variable. Not bad for two buttons! After entering the variable name and pressing [ESC]:

Now in command mode, we can press 'O' to create a line above the current one and go into input mode, and then declare a variable:

Now we need to insert a function call, and since it is already in the clipboard, we can paste it by pressing Ctrl-R, and then "(not a little intuitive, but this is a combination to paste from the standard clipboard), then"; "and [ESC ]:

Misconception number 3: you must be a psycho and / or genius to use it

Well, I hope that, thanks to the explanations and examples above, you have an understanding of the potential of the possibilities provided by vi / vim. It is difficult to learn (see below), but if you are going to code eight hours or more a day for years, then this is the second best investment after the “blind typing” (which you have already mastered, don’t you? If not, start with it). By spending a few weeks now, you will receive dividends all your life.

The point is that with vi your keyboard turns into a specialized gamepad for editing text with almost a hundred buttons, each of which has at least two functions - with cipher and without shifta; Thus, you already have under two hundred functions accessible by pressing one button (not counting the shift) (the author has counted on something a lot, we can safely divide into two). Powerful commands themselves can be combined with each other to get the best result. While typing, this is a standard keyboard, but when you return to command mode, this is the ideal text editing machine.

Example 3: Manipulations with delimited blocks

Another simple example. It works only in vim, because it uses one of its specific move commands. Let's say you are inside a block delimited with angle brackets, which is not uncommon in our day XML:

How to select text inside to copy / edit / delete it? In ordinary text editors, you are forced to remove your hands from the current comfortable position and use the arrows, or worse, with the mouse. Any of these options is not convenient, especially on a laptop. How to do it in vim? You simply use one of the commands to move through text objects, each of which begins with 'i' or 'a' (these characters are also used as editing commands and therefore can only follow after 'd' or 'c' commands) 'i> 'means the current block is delimited with angle brackets, where' i "'is from' inner '. So you can type' di> 'to delete all the text inside the angle brackets:

You can use '(' or ')' to highlight the current block bounded by brackets (or even 'b' from 'block'), '{' or '}', '[' or ']', 'w' for punctuation-separated words, or 'W' for a word highlighted with spaces, preceding 'i' c with any of them for internal content, or 'a' to select delimiters too.

Misconception number 4: "hjkl" to navigate the text?

Many people find it odd to use hjkl instead of arrows. The real reason for this implementation seems to be that terminals like this did not have arrows and the hjkl keys carried additional load . But a side effect of this arrangement is the lack of need to remove your hands from a comfortable position, which is great.

In any case, although at first you will use hjkl to move around the text, having mastered vi / vim you will most likely refuse to use the 'h' and 'l' keys. Why? Because there are much more powerful commands that can move the cursor to the right place of the text much faster. I found that when editing a line, there is always a move command that will take me directly to the desired character, I use these: 'f' complemented by any character whose next entry I want to find, '%' to move along the brackets, etc. When navigating through a file, you can use the commands to go up / middle / bottom of the screen directly, '/' to quickly search, ']]' and related functions for navigation, etc.

Example 4: Pleasant Commands

Some commands are so comfortable that you can forget that you use them. 'H', 'M' and "L" move the cursor to the upper, middle and lower lines of the screen, respectively. 'zt', 'zz', 'zb' do not move the cursor, but scroll the text so that the cursor is at the top, in the middle, or at the bottom of the screen. The '*' searches for the next occurrence of the word, on which the cursor is located forward in the text, the '#' does the same backward. And there are many more such teams ...

Misconception number 5: since we think about the problem 90% of the time, and we program only 10% of the solution, it is almost useless to pump the editing speed.

Well, this is an exaggeration, but this counter-argument is often used against any means of improving the efficiency of code editing. I bet he is contrived.

First, if I need to think about a problem without having to look at the code, I take my bike and go for an hour or so, or two. If the weather is good, it is much nicer than hanging around in front of the computer.

Also, when I need to analyze some difficult problem and come up with a solution, I take a notebook, a pen and try to clear my thoughts with their help.

But, with rare exceptions, it is impossible to work productively without a computer. Indeed, in most cases you need to see the code. And here without a text editor you can not do. And of course, very often you type the text or edit it continuously. Thinking one minute, the next you spend on making the changes that you have thought about. And, of course, you want to use the best tool for this job.

Comfortable editing allows you to remain "in the flow" - a state of maximum concentration and productivity. Masterfully mastering a text editor, you move editing to an unconscious level, freeing up the brain's computational powers for other tasks. A common style distracts you, you use Ctrl-Right, Ctrl-Right, Ctrl-Right, Ctrl-Right, Ctrl-Right to get to the right place in the code, pick up the mouse to select the menu option, click "accept" in confirmation dialog. Vi / vim also allows you to do a surprisingly small number of keys to do exactly what you want.

Other vi users say the same thing, so I'm not alone in my feelings: as soon as you achieve mastery of vi, there are times when, after 30 seconds of explosive editing, you wake up and realize that you have heard the clatter of keys somewhere in the back of the head, while cutting, changing and moving blocks of text. And such moments give an amazing feeling of power.

Example 5: block alignment

Vi and vim know that your code has some kind of structure. Many teams reflect this. Take, for example, 'aB', which was described above - it highlights the current block with curly brackets along with the brackets ('a}' does the same thing) and combine it with the '>' command, which aligns the area indicated by the following command move. Imagine this code:

How often do you meet such a problem? Yes, you can of course insert with auto-alignment ('] p' in vim), but suddenly you forgot, or received such code, not copy-paste, but because you deleted a piece of code above. In general, you just need to align it. In other editors, you move the cursor, press [Tab] or use the shortcut for auto-leveling. But not in vim, just the three keys '> aB' "align block" and you get this:

Cool, right? No throwing with the cursor and the selection of the text, just say what you need and vim does everything. I believe that this is the type of editing that gives you real power over the code and allows you to stay "in the flow."

Misconception number 6: it's just an attachment to a fading past.

Vi is already thirty years old *, and it is still popular. Vim is a complete vi clone, in which more improvements than in vi capabilities, has been alive and well for 15 years now * and is distributed free of charge to almost any existing platform. People who like vi find ways to use it everywhere: there are plugins that allow you to use vi's features in Eclipse, various applications for Mac, IntelliJ IDEA, even emacs are not one, but as many as several built-in vi emulators Emaks, I started with trying to use his keyboard shortcuts, but always ended up with “Mx viper-mode”), I develop and sell the ViEmu family of plug-ins to implement vi / vim emulation in Visual Studio, SQL Server, Word and Outlook, Paul Graham ( here about him on Habré ) still uses vi to develop lisp and arc, T im O'Reilly open vi-mer, SlickEdit and Crisp can emulate vi ...

vi : , vi . , , , , vi/vim . , vi/vim , , , Unix- IDE.

* 16.05.2007