|
My claim is not that motions and the like are not useful constructs. My claim is that most functionality of this sort, whose use-case is not contrived or trivial, has equivalently low-keystroke solutions in nano; these often tend to be more intuitive as well, and sometimes require even less keystrokes/keyboardtime than vim (especially considering the whole enter/exit edit mode extra keystroke, which tends to be conveniently absent in keystroke wars). E.g. dfXa -> Mark, Search, X + Enter, Delete
d/foo -> Mark, Search, foo + Enter, Delete
d6w -> Mark, EndOfWord x 6, Delete (or store 'EndOfWord Delete' as a temp macro, and use a predefined repetition command) To me, '23x' (and to some extent even d6w) is an example of a contrived use-case; while you can come up with ways to minimize keystrokes for such a scenario in nano too, in reality if you have text or code where you need to find the 23rd instance of a character EXACTLY, there's something REALLY wrong with your code/text, in which case '23x' is the least of your problems. In all non-trivial/non-contrived cases, if you need to look up something 23 times, you're probably going to want to walk through those instances as well, and the act of 'counting first then executing the incantation' is likely to cost you far more time spent on the keyboard than what is saved by minimizing keystrokes. And if you really, really need something as arcane as that, and use it often, then you can write a relevant macro easily. No need to bother regular users with that bloat. Somebody else here already mentioned the ^U^U^U^U^U^K vs y5p comparison: this is a prime example of the above philosophy, and I agree. Keystrokes are saved at the cost of actual time spent on the keyboard. At the end of the day, I'd much rather spend 5 seconds on 10 keystrokes, than 10 seconds on 5 keystrokes. And in practice, most people would use a selection instead anyway, resulting in more keystrokes in vim compared to nano to begin with. |