I barely use the regexps. There are 2 things that vi/vim are quite good at that are very relevant today. I don't know of any alternative that is as good.
First, efficiency of bandwidth over an ssh connection. You might think, "Oh but there is tons of bandwidth on the internet today". However, I actually use vim to pair program with people in the UK while I'm in Japan. Vi commands can easily deal with variable latency and still give good performance because you are almost always in command mode. Instead of arrowing down to some character, I simply tell the editor where I want it to go using a language with a grammar. I have very happily coded all day with 300+ ms latency in Vim. For me this is a killer feature that is painful with any other input system. (vi is even better at this because it reduces the number of repaints to a bare minimum).
The second feature is very much related to the first - the use of a grammar for describing what you want the editor to do. With most editors, you press a key and it does something small and specific. With vi/vim you describe things that you want the editor to do with sentences.
This is a great example of the difference between ease of use and ease of learning. vi/vim is very difficult to learn well (or at least it takes a lot of time and practice). But it is arguably much easier to use once you have that learning. It's like the difference between "Pick up glass. Drink beer." and "Move hand. Move hand. Move hand. Grab glass. Lift glass. Move hand. Move hand. Move hand. Tilt glass. Drink beer".
Sure, it's not for everyone, but it's clearly not reasonable to say that the state of the art has improved in these respects. I can think of no other editor that even attempts to solve these problems. If you know of some, I'd be happy to learn of them.
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.
First, efficiency of bandwidth over an ssh connection. You might think, "Oh but there is tons of bandwidth on the internet today". However, I actually use vim to pair program with people in the UK while I'm in Japan. Vi commands can easily deal with variable latency and still give good performance because you are almost always in command mode. Instead of arrowing down to some character, I simply tell the editor where I want it to go using a language with a grammar. I have very happily coded all day with 300+ ms latency in Vim. For me this is a killer feature that is painful with any other input system. (vi is even better at this because it reduces the number of repaints to a bare minimum).
The second feature is very much related to the first - the use of a grammar for describing what you want the editor to do. With most editors, you press a key and it does something small and specific. With vi/vim you describe things that you want the editor to do with sentences.
This is a great example of the difference between ease of use and ease of learning. vi/vim is very difficult to learn well (or at least it takes a lot of time and practice). But it is arguably much easier to use once you have that learning. It's like the difference between "Pick up glass. Drink beer." and "Move hand. Move hand. Move hand. Grab glass. Lift glass. Move hand. Move hand. Move hand. Tilt glass. Drink beer".
Sure, it's not for everyone, but it's clearly not reasonable to say that the state of the art has improved in these respects. I can think of no other editor that even attempts to solve these problems. If you know of some, I'd be happy to learn of them.