5 ms·

>big argument in favour of using mice Yes, I am aware of Acme and Sam and I am aware that good mouse driven interfaces are faster than using keyboard driven in

>big argument in favour of using mice Yes, I am aware of Acme and Sam and I am aware that good mouse driven interfaces are faster than using keyboard driven interfaces. I should point out that mouse driven interfaces are only better than keyboard driven interfaces when designed competently to actually take advantage of mice (e.g. acme). Text editors such as VSCode suck in comparison in terms of their mouse usage, the way Acme uses mice is worlds different from the extremely boring and inefficient use of mice that VSCode has. That aside, the question is not if utilising a mouse well makes for a faster interface than restricting the interface to only using the keyboard. The question is if multiple-cursors are a good use of the mouse. I'm sure there's some situations where multiple cursors are faster than using editor commands, but the point I was making is that in general I've found multiple-cursors to just be a distraction which slows me down. This might be because I don't work from a desktop and use a trackpoint, or maybe because when I do use a desktop I use a trackball. But from what I actually remember, most of my time with multiple-cursors has been spent trying to reason about how applying a certain input in 5 different places will affect the text, and then undoing mistakes. I have found the regular expressions that vim has as well as the structural regular expressions in Sam and Acme to be far better at describing operations which need to occur in multiple places. Please do look into vim's regular expressions, there's a surprising amount of stuff that they can do which most people are not aware of.

dandotway 5y ago
> Please do look into vim's regular expressions So here's an editing task. Given the following in your editing buffer, signed char foo; /* ... 10 more lines ... */ unsigned short bar; /* ... 10 more lines ... */ const char *const s = "Dennis Ritchie little-loved 'const'."; What is the fastest sequence of vim commands to 1. delete 'signed' from signed char foo 2. delete 'short' from unsigned short bar 3. delete the two occurrences of 'const' from 'const char * const s' With VSCodium 1. Alt-click just past the end of each of the 4 strings to be deleted. 2. Ctrl-Backspace. 3. Done. This involves 1. Three keyboard keys total (Ctrl, Alt, Backspace), each pressed and released once. 2. Four mouse clicks total, plus four target aiming tasks for these clicks. This sequence requires zero thought or planning prior to execution. I want to see the keyboard keystroke count for your best vim sequence, which will require a pause to plan out prior to execution, whatever you come up with. > This might be because I don't work from a desktop and use a trackpoint, or maybe because when I do use a desktop I use a trackball. 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, https://humanbenchmark.com/tests/aim There is no way you are hitting the curve peak around 400ms with a trackpoint/trackball/touchpad. There is a reason essentially all pro gamers who compete for millions in sponsorship bucks use mice instead of touchpads/trackpoints/trackballs: mice are faster. (There might be like 1 out of 1000 pros who use a trackball for Starcraft-like games, but none of them are top-ranked.) Also try https://aimtrainer.io/ I agree VSCodium is not as cool as Acme, but it is nevertheless very efficient or I wouldn't use it over Vim, Emacs, or Acme. 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. But I do claim that if and when text editing competitions for prize money are held, those who use mouse-driven multiple selection will be at a decisive competitive advantage over those who don't. This is just a claim which I cannot prove until such competitions are held. And, again, if a mouse makes you less happy than something slower, then the tortoise beats the hare, so to speak.
- Arch-TK 5y ago
  >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.

dandotway 5y ago

> Please do look into vim's regular expressions So here's an editing task. Given the following in your editing buffer, signed char foo; /* ... 10 more lines ... */ unsigned short bar; /* ... 10 more lines ... */ const char *const s = "Dennis Ritchie little-loved 'const'."; What is the fastest sequence of vim commands to 1. delete 'signed' from signed char foo 2. delete 'short' from unsigned short bar 3. delete the two occurrences of 'const' from 'const char * const s' With VSCodium 1. Alt-click just past the end of each of the 4 strings to be deleted. 2. Ctrl-Backspace. 3. Done. This involves 1. Three keyboard keys total (Ctrl, Alt, Backspace), each pressed and released once. 2. Four mouse clicks total, plus four target aiming tasks for these clicks. This sequence requires zero thought or planning prior to execution. I want to see the keyboard keystroke count for your best vim sequence, which will require a pause to plan out prior to execution, whatever you come up with. > This might be because I don't work from a desktop and use a trackpoint, or maybe because when I do use a desktop I use a trackball. 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, https://humanbenchmark.com/tests/aim There is no way you are hitting the curve peak around 400ms with a trackpoint/trackball/touchpad. There is a reason essentially all pro gamers who compete for millions in sponsorship bucks use mice instead of touchpads/trackpoints/trackballs: mice are faster. (There might be like 1 out of 1000 pros who use a trackball for Starcraft-like games, but none of them are top-ranked.) Also try https://aimtrainer.io/ I agree VSCodium is not as cool as Acme, but it is nevertheless very efficient or I wouldn't use it over Vim, Emacs, or Acme. 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. But I do claim that if and when text editing competitions for prize money are held, those who use mouse-driven multiple selection will be at a decisive competitive advantage over those who don't. This is just a claim which I cannot prove until such competitions are held. And, again, if a mouse makes you less happy than something slower, then the tortoise beats the hare, so to speak.

Arch-TK 5y ago
>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.