I by no means agree with the guy you're replying to, but I don't think your vocalized example is fair. With vim, your state is in the "sentence" you've written. With a typical editor your selection is in the state of your editor, primarily its selections. It's more like "Do this here." vs. "Look here. Do this."
One thing I used to do is visit http://www.vimgolf.com/ and compete with the best solutions there. Aside from a higher usage of meta characters (which is a modal vs. quasimodal thing, rather than a sentence vs. select thing), my editor of choice (Sublime Text) rarely lost out.
There is the caveat that some things that are great for golfing are relatively useless elsewhere (eg. numeric modifiers) and vice-versa (command panel: trim trailing spaces). I miss the later in vim much more than I miss the former in typical editors... although I still hacked it into Sublime anyway.
We actually have several licenses of Sublime kicking around at work because everybody moved over to Vim. I know several people who are really fond of Sublime, but lack of a text mode put it at a bit of an evolutionary disadvantage in our shop since we do a lot of remote pair programming over SSH. It's a bit of a shame since we are almost a monoculture now (one guy still uses Emacs and 2 are vim/sublime bilingual -- every one else is on vim pretty much exclusively). I think it's nice to have some diversity to keep people thinking of the possibilities. I'm in the process of moving over to Evil mode in Emacs pretty much for that reason.
Probably my example was a bit poor. I wasn't trying necessarily make the argument that Vim is more keystroke efficient than other editors. I used Emacs for 20 years before I switched to Vim and I was quite efficient with it. I was more trying to convey the idea that the way of thinking was different. Instead of concentrating on the immediate motion of the cursor, I'm concentrating on the structure of the document.
Lately I've been thinking it would be nice if someone were to think a bit more about extending the state of the art in modal editors. Vim was a nice extension of vi, but the grammar is still pretty crufty in a lot of places. It would be cool to rethink it from scratch, I think.
> I was more trying to convey the idea that the way of thinking was different. Instead of concentrating on the immediate motion of the cursor, I'm concentrating on the structure of the document.
In what way does the multiple selection model not concentrate equally on the structure of the document? It's true that vim has a larger vocabulary than a typical editor, but its grammar is actually weaker. For example, I know of no way to combine two arbitrary motions.
Consider the case where you want to delete all strings containing the word die, where the string grammar is non-trivial. In a selection-based language you can
* select-all-"die", manually checking that they're inside strings
* select-enclosing-block
* delete
If one had a language-aware string token finder (and, frankly, a token-aware editor would be amazing - maybe I should edit Sublime to do that...), one could even
* select-all-string-tokens
* select-all-"die" inside selection
* select-enclosing-block
* delete
This is a very structural approach. I don't know a neat way of doing this with vim. (I'd be happy to learn I'm wrong!) There are other examples, like where one wants to work on some collection of things in lockstep and vim's inability to hold state through selections between commands results in a difficult workflow. The multiple selection model remains semantically unperturbed.
I would very much be interested in a modal editor that doesn't just try to copy vim - working on multiple selections with a large vocabulary and syntax-awareness would be wonderful. I also find some things, like temporarily restricting actions to a subset of selections, needlessly hard in Sublime. There's a lot that can be done!
Multiple selection does seem to be quite a powerful feature. I've never actually used it myself, so I'm not completely clear on all the possible workflows, but it's something that I know the Sublime people I work with miss in vim.
Speaking of token aware editing, smalltalk had an AST aware "editor" called a "refactoring browser". It could even infer the type of a variable by running tests and seeing what type the variable held in the running code. This is where you can get some crazy utility happening with automatic refactoring. Unfortunately most languages these days are needlessly complicated to parse (ahem... ruby).
I am toying with the idea of writing an Evil like mode in Emacs that gives the utility of vim, but without some of the cruft from vi. I think Emacs is a good platform to do it in since it gives you a lot for free (especially a nice lisp interpreter to implement features in ;-) ). However, I have far too many things on the go as it stands :-(
To be clear, I it's not trimming trailing whitespace I miss; it's fuzzy, graphical command search of human-readable phrases. I'll never remember a shortcut for shuffling selections, but I'm more than happy to type "shuffle" and use my eyes.
One thing I used to do is visit http://www.vimgolf.com/ and compete with the best solutions there. Aside from a higher usage of meta characters (which is a modal vs. quasimodal thing, rather than a sentence vs. select thing), my editor of choice (Sublime Text) rarely lost out.
There is the caveat that some things that are great for golfing are relatively useless elsewhere (eg. numeric modifiers) and vice-versa (command panel: trim trailing spaces). I miss the later in vim much more than I miss the former in typical editors... although I still hacked it into Sublime anyway.