1. Even in those situations, I believe a veteran vim user would still beat someone using a mouse.
2. That said, the situation you describe is relatively rare: when coding you typically will be addressing blocks of text defined as functions; sharing an indent level ("ii" selects these); or otherwise selectable by vim in 2-3 keystrokes.
3. Even when that's not the case and the vim selection takes, say, 5 or 6 keystrokes, it has the advantage that your fingers never left the home row, so there is no wasted time "resetting."
4. Just as a tip: doing a "/" search for 2-3 characters after making your visual selection is typically enough to define your block, and will often be faster (and less of a cognitive distraction) than trying to eyeball or count the number of lines and doing a "10j" motion or similar.
That doesn't seem to work. Am I missing something?
Also, relative line numbering changed my life.
If I had to "criticize" one of Vim's concepts, it would be its way of overriding registers in very unintuitive situations, but I'm certain I'll get used to that, too. When you're aware of it, it's simple to avoid using "_ first.
Edit: OTOH, selecting a piece of text and replacing it with p is quite irritating: The 0 register will still contain its original data, but " will contain the replaced text. I am not aware of how to disable this effect ("_p will paste from the black hole register, which doesn't help in this case).
so all in all it's mb<search>me`bv`ex
now if your say you can search your text faster with your mouse than with keystrokes you have a different problem: you don't know how to use the search features in vim efficiently.*
I think it's nearly impossible to be faster with a mouse than a keyboard when it comes to search.
*and yes, to be efficient at it there's a 2 month learning curve that pays dividends over the next 30 years of your programming career -- it's up to you if you think it's worth the investment or not. Use it or lose it, if you don't make an effort you'll stay at your local maximum.
why not just?
v<search>xAnother useful visual mode is Visual Block (<ctrl>+v), for deleting/yanking, replacing block across multiple lines.
With cursors you just hold shift and use down-arrows to (visually) select the lines you want. Add in Ctrl and you can move word-boundaries, add home-end and you can do beginning/end lines / pages too.
The whole thing is still quicker than vi but with the added benefits of getting much more visual feedback on what is happening and the ability to use the mouse to also quickly select things.
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
> We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
> - Test subjects consistently report that keyboarding is faster than mousing.
> - The stopwatch consistently proves mousing is faster than keyboarding.
(PS and caveat emptor: it's now 30 years since that study was done. Also, I personally firmly enjoy my vim. I just try to stick to liking it because I like it, not because it makes me an uberuser. An uberuser will probably be an uberuser no matter what.)
But I have some hope for merging the ideas of acme with proper touch screens/digitizers.
I would too. But I'd be willing to wager on the results beforehand.
> b) see if it makes a difference in productivity. (Most of what makes me slow at work is trying to understand technical problems, not trying to find parts of text in my editor.)
There's no doubt that things like understanding technical problems, avoiding procrastination, and many non-technical factors are the high-order bits of productivity.
That said, the context of this conversation is text-editor optimization. Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around.
My thoughts exactly (although mine might not have been worded that well :) ).
Vim-bindings are like a REPL, but on a different level. If you compare a REPL to a loop of "save, compile, run, enter passwords, wait for a specific event to trigger", you might get a grasp of what a Vim-enthusiast gets out of the editor. They've fixed the thing to fix and moved on while you're still trying to find out where your mouse movement went.
That might sound a bit exaggerated, but for the skeptics, I propose an experiment: Switch your keyboard to a different language (say Turkish, if you're very brave) and try to code for a couple of minutes. I do that regularly (my colleagues don't use the same layout as me), and I'd wager it's about the same level of annoyance as not being able to use Vim-bindings if you're used to them.
I'm not saying that there aren't other effective ways of editing text, I'm merely finding that the defaults aren't very good.
I couldn't agree more. For me, that's working with a Logitech Anywhere MX mouse in Sublime Text. I imagine how I want the text on screen to be transformed and it just happens without conscious thought.
My big complaint is that the buttons eventually start to fail. Single clicks will sometimes register as double clicks and click-drag operations start to drop early.
When I was a DBA, I did all sorts of data normalization stuff, and the Unix pipeline of tools (vim, sed, awk, some perl) was necessary and I was adept at it. Today, I don't do it that often, and it's quicker to just use Excel or whatever for slicing and dicing. It's not worth the overhead to save 10 minutes of manual tasking.
You'd see this when you did green screen to web transformations in enterprise projects. Training would 1/10 the effort, and knowledge based processes would be faster, but the new people would be alot slower than the veteran keyboard operators.
That's me too. I spend a lot of time each day reading and that's a lot of scrolling with my mouse and ctrl-clicking on works to jump to definitions or declarations. Text editing speed is definitely not a bottleneck for me.