Multiple modes allows the same keys to do different things in different modes, there isn't much more to it than that.
Say, at a Bash shell prompt in a terminal window, pressing Ctrl+R starts "reverse command search" mode, so that pressing letter keys searches for commands entered in the past, rather than entering a new command. In this mode, up and down move through search results, rather than moving through the entire command history like in "normal" mode.
Lots of software has modes, the unusual thing about Vim is that they have names, and that there is a mode with a focus on navigation.
Why have a mode focused on navigation? Is there something this mode allows beyond navigating? What would be impossible to do if you didn't have this mode?
The keyboard allows you to navigate too, without the need for a mode.
Keep in mind that a lot of the keyboard features we take for granted weren't always present on early terminals. Navigating is a lot harder if you don't have, say, arrow keys. In that case, a separate mode makes a lot of sense for getting around (no arrow keys? Just map hjkl to them in navigation mode). Plus the same command can do different things depending on mode, so there are less distinct patterns of keypresses to memorize. Yes, you could do everything as a series of chords (like in emacs), but I don't think it's necessarily superior.
Here's a list of some navigation mode commands. You can probably come up with reasonable ways to do them with only the keyboard & none of the alphanumeric or punctuation keys used alone, but would that be any easier?
http://www.thegeekstuff.com/2009/03/8-essential-vim-editor-n...
It's used for text manipulation, too - the advantage lies in the fact that the same navigation keys are used to operate on blocks of text. For example, move to the next close-parenthesis can become copy everything up to next close-parenthesis, move to the next blank line can become indent everything up until the next blank line, move to the end of the line can become delete everything up to the end of the line, etc.
(For the record - I think it was a legitimate question. Upvoted!)
I interpret it as a positive sign when someone downvotes without an explanation (live above). It's a sign they don't understand a topic well enough to refute its main point. I'm sorry if the comment above also caused you to grow indignant.
A better response would have been to zoom in at the main argument and say the most important thing there is about it.
If you aren't downvoted enough you are probably not revealing anything controversial.
I'm not sure how true that is and I might be able to prove it.
(1) One way it could help is: if I could get feedback about where I went astray. That's what I want to know when I'm downvoted. I don't care about a karma point, I care about learning something new.
Which makes me wonder: would it help to ask people explain why they downvoted something -- even if their username doesn't get attached to an explanation that becomes public?
(2) Here's an instance where it actually helped: [1]. Me explaining in [2] why [1] was downvoted (which was at something like -1 at the time) lead into [1] being voted again and [2] being upvoted too for clarifying the situation.
(3) This comment is aligned with HN's own request for providing feedback about what's good and bad for HN comments [3].
(4) You should be alarmed when you see a guilty word like "never" used. Particularly if you are the one using it. It's an alarm that indicates you are going to an extreme to justify a position. If what you say is evidently true, you wouldn't feel the need to try hard to qualify it. Or at least, when I made this argument in [4] people voted 20 points for it (which you dang can verify as an administrator).
(5) These arguments suggest reviewing the site guidelines and it's hard to dismiss them as useless. They could improve HN.
I fully understand if what you've discovered studying downvotes is that dealing with them differently leads into more problems than it does dealing with them with the advice of "don't post about being downvoted". I also understand if you are not willing to deal with those problems now. But saying "it never helps" sounds far fetched. You are claiming there's nothing that can be done about downvotes, ever. That's a strong claim to make, especially in a field that's only 50 years old.
Its reason for existence is historical, but it persists because it is useful.
"Normal mode" (the most common mode other than insert mode) uses key bindings that wouldn't be possible in insert mode, rather than using the ctrl/alt/etc. keys for binding. For example, hovering over a word and typing ciw (change-in-word) will delete the word and place you in insert mode. There is a nice grammar and logic to the default key bindings (mostly.)
(IMO) When you are experienced with Vim you will spend most of your time in normal mode. This has a few benefits. For one, undo in Vim is "transactional" as you enter and leave insert mode (its a little more complicated but nevermind.) Everytime I have to use other editors (like VS with the VSVim extension) it drives me batty when I have to undo/redo one-character-at-a-time or with some time based batching that I don't understand. (Plug: the GUndo.vim plugin gives you a usable interface to Vim's undo tree. It's not super common for me to need this, but when I do it is a godsend. (If you've ever done undo, made some edits, and wish you hadn't undone after all, this is for you.)
Efficiency trumps tradition in this istance. The reason for horse carriages is historical too and persists because it is useful but a horse carriage isn't as efficient as a car.
One measure of effectiveness would be: to count the number of keystrokes needed to do something in vi compared to other editors.
What I have found is that ALL editors have modes. Most default to edit mode, and require key sequences to invoke other commands (Ctrl, Alt, Shift, Function keys, Menu choices, etc), then drop you back into edit mode.
Vi chose _a_ way of working. Turns out, a lot of folks have taken to it over the years. (And a lot haven't. They're nice people, too) :)
If you have multiple modes you can basically reuse the entire keyboard for commands. That's one advantage that is impossible to achieve in non-modal editors. Ctrl-ing, Alt-ing, Shift-ing stuff just isn't the same, especially as those commands get more and more complex.
Because as a programmer your time is dominated by editing rather than creating text, therefore it is more efficient for every key to default to direct access to an editing function.
That's too broad of a stroke on what a programmer does with text. It's not just about editing. It's also about (a) moving to the point where you want to edit, (b) moving to an other point right after you just finished editing. Switching between the two becomes harder when you always have to Escape, compared to having direct access to an arrow key.
And (c) about editing. Why type an extra character (i for insert) to let you insert? Why not just type to insert?
In modern vim you do have direct access to the arrow keys. Rarely is this meaningful, for someone skilled in vim.
It can potentially be faster if you need to move just a couple characters over, but if you need to move 25? It winds up being something like: Esc 22hhhh
People navigate by jumping across words, across features, searching...
I wonder if there's navigation modern vim doesn't offer. Can you tell if or how you can do the following in vim?
In Emacs, Ctrl-<up arrow> moves the cursor ahead of a block of code. If you had a for loop for example, with a blank line where the for begins and a blank line where it ends, and the cursor was at the blank line where it ends, pressing the two keys Ctrl and <up arrow> would put you in the beginning.
How would you do this in vim? Would you have to first gauge how many lines of text up you should move?
Potentially depends a bit on the language and what plugins &c you have installed. For C on a basic install, you can say [{ to jump to the enclosing { (and there is the symmetric ]} as well). You can also use { and } to step over "paragraphs". And of course, if your goal is to replace the body of the for loop, ci} will delete everything inside the innermost containing {} and switch you to insert mode.
Yes, but unlike every other reply, I actually answered in one sentence didn't I? The fact that my sentence is difficult to grok for someone who is not already familiar with vim is hardly my fault.
But I'll elaborate on your points:
> It's not just about editing. It's also about (a) moving to the point where you want to edit
This is implicitly part of editing. vim offers more ways to move than any other editor, this goes directly to my point. Whereas in most editors you are crippled without a mouse, or at least clumsily moving around with arrow keys plus chords, vim have several movement commands that would not be possible without normal mode because you would just be typing text rather than powerfully moving around your document (eg. (, ), [, ], e, g, f, F, t, T, b, etc). Those examples are in addition to hjkl which are equivalent to arrow keys but of course more powerful because you can add number before them.
> Switching between the two becomes harder when you always have to Escape
No it's not, escape is just what you hit to finish a command. It's no different than hitting return at the end of a paragraph. It becomes reflexive and is far less of a burden over time than the extra key stroke of holding Shift, Ctrl, Alt, or Command keys which is taken for granted by non-vim users as the only way for keyboard commands to exist.
> compared to having direct access to an arrow key.
You can have direct access to arrow keys in vim if you want, but people recommend against it because newbies tend to use them as a crutch to avoid learning better movements. I'm not a purist, and I keep arrows in insert mode, but I map them more powerful things like switching tabs in normal mode.
> Why type an extra character (i for insert) to let you insert? Why not just type to insert?
Because in this one sentence I am typing there are 20 extremely powerful commands that I'm giving up in order to have the convenience of not typing `i` before I write the sentence.
Additionally, what if I want to insert text on a new line (o, O), or if I want to replace some text that is already there (c, C, cw, cW, c, 5cc, ca", ci[, etc)? `i` is not just an extra requirement, it's a choice about what kind of edit I want to make. Furthermore, when I'm done, if I want to insert the same text again I just hit `.`. Gaining fluency in this type of workflow leads to super optimized workflows, like manually find and replacing the word foo with bar:
/fooc2fobarn.n.n.n.n.n.n.n.n.n.n.n.n.n.n
Of course find and replace is a special case, but the fact that you can do something manually with atomic key commands that merits a custom UI in other editors ought to give you pause. The pure text editing workflows that are possible in vim just with fluency in the basic commands are unparalleled.
IDEs can do a better job by building advanced tools for specific languages. Modern editors can do a better job integrating into the OS. Emacs does a better job at customizability. But nothing matches vim's raw editing capability on arbitrary text.
Say, at a Bash shell prompt in a terminal window, pressing Ctrl+R starts "reverse command search" mode, so that pressing letter keys searches for commands entered in the past, rather than entering a new command. In this mode, up and down move through search results, rather than moving through the entire command history like in "normal" mode.
Lots of software has modes, the unusual thing about Vim is that they have names, and that there is a mode with a focus on navigation.