|
>Example involving signed, etc. I am aware that mouse based use of multiple cursors can be faster in some situations. But I would highly question if the example you gave isn't unique and contrived. If I was performing a local refactoring task like the one you described, I certainly wouldn't read the code first and then buffer up all the disparate editing tasks which I have accumulated. Especially since mentally I would have to categorise them into a category suitable for this kind of editing task. I would most certainly perform the refactoring tasks as I encountered them, navigating with `h`, `j`, `k`, `l`, and `w` to run `daw`. Moreover, if I were using a mouse based text editor, I would be double-clicking each instance and hitting backspace as I scanned the text. If this was a global refactoring effort, I wouldn't be using vim, I would be using more advanced language aware tools to perform whatever changes I needed (although it wouldn't be too difficult to turn this into a globally executable regular expression). In fact, double clicking and backspacing is not really particularly slower than the action you described and is certainly more flexible in that you can perform other edits (ones which may not be describable as whole-word-deletions) in between. Realistically, I am not that interested in counting clicks and keystrokes and more interested in effort. It's not really effort to perform a refactoring task where you edit as you read. Not something I care that much about trying to optimise. I care more about cases where there's multiple very similar editing tasks which need to be repeated across a set of similar lines. In these cases, the edit operation is usually more than just "delete a word" and the number of impacted lines is more than 4. In these cases the mental effort of trying to think of how to perform the operation without misaligning things, accidentally going too far or using the wrong edit command. Especially in more modern neovim, there's even a preview for what's happening. Even without the preview, it's trivial to apply an edit, see there was a mistake, undo, modify the operations and reapply it. This is much better than performing a multi-cursor edit, realising there was a mistake and at best having to reapply all the commands after the mistake and at worst having to start from scratch. >Multiple peer-reviewed human-computer interaction studies have shown that for a broad range of pointing and editing tasks the mouse is faster than touchpads, trackpoint nipples, trackballs, and pens. (I do use a pen occasionally and if not for the pressure/tilt sensitivity it would be mostly pointless.) There's no need to dig into the literature because you can just try it yourself: next time you have both a mouse and your trackpoint/trackball handy try benchmarking your performance at, I am aware of the fact that the mouse is a far better aiming tool than a trackpad or trackpoint or trackball. The problem is not the aiming, as I said, but rather the mental effort required to translate complex editing tasks into multiple-simultaneous edits. At best it's no more difficult than translating a complex editing task into an expression, at worst it's more difficult. >If you do not personally like mice or mouse driven multiple-cursors that's cool, enjoying the journey is often more important than getting to the destination as fast as possible. I never said I didn't like mice, I said that multiple cursors are a gimmick which is less efficient than the same operation performed with other tools. |
My Dear Dude, you are surely aware that computer editors are Religion among programmers, that vi vs. emacs, tabs vs. spaces, etc., have been fiercely debated for decades and will continue to be fiercely debated for decades to come. Thus, like all matters of politics and religion, if you are going to insult the Editor Religion of your fellow programmer and call it a gimmick, you might do well to at least accept the challenge when foul is cried and the gauntlet is thrown down demanding a scorable, quantifiable, objective, numerical measure of your performance claim that settles the question as fact rather than opinion.
But you would do better still to refrain from insults like 'gimmick', especially when the programmer whose favored multi-cursor feature you are insulting has demonstrated a deep interest in the history of computer editors, naming out ed/vi/vim/emacs/Sam/Acme/VSCodium, etc., and fully understands how to do ':%s/foo/bar/gc' in vim and the more powerful things documented by ':h :s' within vim and the even more powerful things yet in Acme involving the 'x' and 'X' commands but despite all this has found that multi-cursor can usually finish the edit before even half of that ':s///' command can be typed or a suitable regular expression mentally devised that gobbles the correct substrings on the correct lines without accidentally gobbling incorrect substrings on incorrect lines or incorrect substrings on correct lines or correct substrings on incorrect lines.