Noah's Mark - Latest Comments in the keyboard/mouse and “bandwidth”

Re: the keyboard/mouse and “bandwidth”

John Floren — Tue, 05 Aug 2008 18:13:16 -0000

I agree that the worst part of it is moving your hands to the mouse and getting the cursor to the right place, moving back to the keyboard to type the command, and then switching back to the mouse again to select and execute the command, but I also find it convenient in its own way.
I use acme exclusively for editing on Plan 9 and emacs or vi for editing on UNIX. I don't work with Windows if I can help it but vim is the preferred option there too.

Re: the keyboard/mouse and “bandwidth”

noahrichards — Mon, 04 Aug 2008 22:54:42 -0000

So it sounds like you have to do the following:
1) You are typing along (hands on keyboard) and you want to replace something in a piece of text
2) You select the paragraph (hand on mouse) and move the mouse somewhere
3) You type in "edit s/foo/bar/g" (hands on keyboard)
4) You middle click it (hand on mouse)

The slowest part of using an editor is the movement back and forth between keyboard and mouse, I think, so this still feels suboptimal. In vim, for example, you could do the following:

1) You are typing along and want to change text in the paragraph
2) You select the current paragraph with "vip" or "vap": visual mode ("select") inner/"a" paragraph (the current paragraph) (more below).
3) You type ":s/foo/bar/g" and press enter

No movement of the hands, no movement off the keyboard.

For #2, you can replace the "p" in that with any of the following:
"w" - word
"s" - sentence
"[" or "]" - a "[]" block
"(" or ")" or "b"- a "()" block
"{" or "}" or "B" - a "{}" block
"<" or ">" - a "" block
" or ' or ` - a quoted string
"t" - a tag block, a la html (e.g.: "<foo>sometext</foo>")

You can also replace "v" (for selecting) with other commands like "d" (to delete) or "c" (to replace) or "y" (to copy). And the difference between the "a" and "i" version ("a" block vs. "inner" block) is that the "a" version includes the delimiters of the block.

The command remains, in a sense, for further use: pressing "." immediately runs the last command (so if you move the cursor to another paragraph and press ".", it will do it again). Pressing ":" and then the up arrow key will scroll through your history (if you've typed a part of something, like ":s/", it will only complete history items that match what you've typed so far). If you want to save it around, type "qa" (record macro into register 'a'), do steps 1-3, then hit "q" again to stop recording. "@a" runs the macro in register 'a'.

The paper is an interesting read, and I do believe that using the mouse for selecting text is faster for most people than would be the vim keyboard equivalents (my coworker uses gvim for this very reason, but I stick to just vim). However, I think that anything that requires some use of the mouse is still suboptimal to a solution that provides an optional mouse interface. Then again, to each their own :)

Here's a paper from the author of vim (Bram Moolenaar) about effective editing in vim: http://www.moolenaar.net/habits.html

Re: the keyboard/mouse and “bandwidth”

John Floren — Mon, 04 Aug 2008 12:29:40 -0000

#ifdef ADVOCACY
Regarding the keyboard/mouse idea, I would say that a system must either provide keyboard shortcuts OR allow the user to accomplish almost any function in a small number of mouse-clicks. I personally enjoy a Plan 9 editor called "acme"; although there are very few keyboard shortcuts besides ^E for end of line, ^A for beginning, and left & right arrows to move one character at a time, it allows you to compose and run ed/sam-style editing commands on any selected text, easily pipe it through external programs, etc. Basically, my only desire would be for ^F and ^P to move forward and backward instead of the arrow keys; the interface allows me to work quickly enough without extensive shortcuts.
For example, to replace all instances of "foo" with "bar" in a paragraph, I just highlight the paragraph, move my mouse to the file tag-line, type "Edit s/foo/bar/g" and mid-click it. It may take a bit longer than vi, but the command remains for later editing/use, which helps reduce time spent later.

The paper is a bit old, but interesting: http://plan9.bell-labs.com/sys/doc/acme.html
#endif /*ADVOCACY*/