6 ms·

I tried to make vim work like VSCodium (VSCode on telemetry diet), but found it too hard and gave up. 1. How well do you handle the mouse in xterm? Vim actuall

I tried to make vim work like VSCodium (VSCode on telemetry diet), but found it too hard and gave up. 1. How well do you handle the mouse in xterm? Vim actually has fantastic mouse support in xterm (:set mouse=a), e.g. you can use focus-follows-mouse scrollwheel to scroll individual split content panes, drag click to resize the split dividers, etc. (Although, last time I tried under WSL with the old-school win-console, vim's focus-follow-mouse scrollwheel scrolling didn't work there whereas emacs did work (with xterm-mouse-mode)). 2. Can you handle multiple cursors gracefully (vim-visual-multi) with the mouse like VSCodium? Emacs doesn't have a non-buggy multi-cursor mode and I gave up on achieving this with Emacs. I just use VSCodium now, which means allocating over 300MB of system RAM and gigabytes of dedicated graphics VRAM for its 'HW accelerated' rendering that decelerates all other HW graphics rendering on my machine.

Arch-TK 5y ago
You can achieve a significant portion (if not more) of the things that people use multiple cursors for in other editors (or even in vim) with just plain vim regular expressions and other features. Every time I've used multiple-cursors (either in vim or other editors) I've found it just plain slower, less precise and less powerful than plain vim commands. I would recommend looking at the features vim has to offer and learning them to see if maybe they can make up for the lack of native multiple-cursors support.
- dandotway 5y ago
  The Acme editor, used by C creator Dennis Ritchie, converted me to the Rodent Religion. The mouse is the fastest way to point to something on your computer screen, especially a quality gaming mouse with mouse acceleration disabled. Pointing at things on a computer screen and clicking is a highly competitive activity involving billions of dollars annually; pro gaming mouse designs have evolved to be lightweight and extremely efficient at this task. Pianists can rapidly move their hands to 100% accurately strike keys more than a foot away at blink-of-the-eye speed because they practice, and master mouse users can flick their hand from keyboard to mouse to keyboard again at blink-of-the-eye speed if they practice. Anchoring at the keyboard is not the fastest way to edit text. There needs to be a text editing competition organized with prize money. Then shall all the world see that mouse users best the Rodentless in battle. If I need to double-backspace five different caret positions visible on screen, I can Ctrl-click (or Alt-click) to set multiple cursors faster than a master vimmer's brain can devise a suitable ':[x,y]s/.../.../g' command to accomplish the same thing. I know this because I've used vim more than 20 years, and I also learned ed's and sam's editing languages used by the original Unix gods. The Unix gods switched to the Sam editor in the early 1980s which is a bit like a mouse-oriented re-imagining of vi. Then some switched to Plan 9's Acme in the 1990s, which retains Sam's editing language. The Sam/Acme editing language is not line-oriented like ed/vi/vim, e.g. ':#3,#42' selects character 3 through 42 regardless of how many newlines are between char 3 and 42 and does not select to the beginning of the line before char 3 nor to the end of the line after char 42. You can also do ':/re1/,/re2/' and unlike vim this won't grab to the beginning of line before /re1/, etc. Acme doesn't have multiple cursors though and needs some TLC, it doesn't talk to an X server efficiently and draw pixels efficiently because it's based on Plan 9's drawterm. VSCodium does everything I need but is ultra-bloated and I'd love lighter weight.
  - Arch-TK 5y ago
    >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.
tombh 5y ago
I don't use the mouse much, but yes, certainly in my Alacritty/tmux terminal, the mouse selects, moves pane boundaries etc. I've never actually tried a multi-cursor, I have a feeling it might suffer the same fate as the auto cursor positioning you get from snippet completion. But that specific bug I've fixed locally

Arch-TK 5y ago

You can achieve a significant portion (if not more) of the things that people use multiple cursors for in other editors (or even in vim) with just plain vim regular expressions and other features. Every time I've used multiple-cursors (either in vim or other editors) I've found it just plain slower, less precise and less powerful than plain vim commands. I would recommend looking at the features vim has to offer and learning them to see if maybe they can make up for the lack of native multiple-cursors support.

dandotway 5y ago
The Acme editor, used by C creator Dennis Ritchie, converted me to the Rodent Religion. The mouse is the fastest way to point to something on your computer screen, especially a quality gaming mouse with mouse acceleration disabled. Pointing at things on a computer screen and clicking is a highly competitive activity involving billions of dollars annually; pro gaming mouse designs have evolved to be lightweight and extremely efficient at this task. Pianists can rapidly move their hands to 100% accurately strike keys more than a foot away at blink-of-the-eye speed because they practice, and master mouse users can flick their hand from keyboard to mouse to keyboard again at blink-of-the-eye speed if they practice. Anchoring at the keyboard is not the fastest way to edit text. There needs to be a text editing competition organized with prize money. Then shall all the world see that mouse users best the Rodentless in battle. If I need to double-backspace five different caret positions visible on screen, I can Ctrl-click (or Alt-click) to set multiple cursors faster than a master vimmer's brain can devise a suitable ':[x,y]s/.../.../g' command to accomplish the same thing. I know this because I've used vim more than 20 years, and I also learned ed's and sam's editing languages used by the original Unix gods. The Unix gods switched to the Sam editor in the early 1980s which is a bit like a mouse-oriented re-imagining of vi. Then some switched to Plan 9's Acme in the 1990s, which retains Sam's editing language. The Sam/Acme editing language is not line-oriented like ed/vi/vim, e.g. ':#3,#42' selects character 3 through 42 regardless of how many newlines are between char 3 and 42 and does not select to the beginning of the line before char 3 nor to the end of the line after char 42. You can also do ':/re1/,/re2/' and unlike vim this won't grab to the beginning of line before /re1/, etc. Acme doesn't have multiple cursors though and needs some TLC, it doesn't talk to an X server efficiently and draw pixels efficiently because it's based on Plan 9's drawterm. VSCodium does everything I need but is ultra-bloated and I'd love lighter weight.
- Arch-TK 5y ago
  >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.

tombh 5y ago

I don't use the mouse much, but yes, certainly in my Alacritty/tmux terminal, the mouse selects, moves pane boundaries etc. I've never actually tried a multi-cursor, I have a feeling it might suffer the same fate as the auto cursor positioning you get from snippet completion. But that specific bug I've fixed locally