8 ms·

Emacs and the mouse: A modest defense of the rodent

145 points by signa11 3y ago

anthk 3y ago
The magic of Emacs is that you can set it up the way you like. On mousing, it depends. Faster in some cases for making changes on editing and browsing the web in eww if you don't care about ctrl-s.
- oblio 3y ago
  > The magic of Emacs is that you can set it up the way you like. Can you set it up to: 1. have tabs (like in Vim) 2. have the command bar/line/whatever it's called at the top ? :-)
  - klibertp 3y ago
    Tabs are built-in from a few versions, see https://www.gnu.org/software/emacs/manual/html_node/emacs/Tab-Bars.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Ta... > have the command bar/line/whatever it's called at the top I think what you mean is called a mode-line: https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Mo... (or do you mean the thing where you type commands, like C-S-p in VS Code?) To make it display at the top of the buffer window you'd need to repurpose a header line with some custom config. There might be a package for it. Do you have a screenshot of how you'd like it to look like?
    - oblio 3y ago
      VS Code Ctrl-Shift-P, yes. And I'd want the results to drop down not to climb up.
      - klibertp 3y ago
        Very possible, yes: https://github.com/tumashu/vertico-posframe https://github.com/tumashu/vertico-posframe. You can position the box anywhere you want by configuring the parameter: vertico-posframe-poshandler . posframe-poshandler-frame-top-center ^^^^^^^^^^^^^^^^ I use `posframe-poshandler-frame-bottom-center`, which looks like this: https://klibert.pl/statics/vertico-screenshot.png https://klibert.pl/statics/vertico-screenshot.png Those ugly things at the top of the window are tabs - they can look much better if you use a modern theme (personally, it never bothered me enough to put time into configuring them).
medo-bear 3y ago
one of the better emacs+mouse actions for me is rectangle select with C+M+'hold left button and select'
- deafpolygon 3y ago
  Alt+Shift+Mouse in VS Code
  - medo-bear 3y ago
    Can VS Code do this in virtual console or even in terminal?
    - deafpolygon 3y ago
      Yes, Alt+Mouse1, then you can Ctrl+C to copy.
      - medo-bear 3y ago
        As far as I know VS Code only runs within a windowing system, not inside a terminal. On the other hand I can run my Emacs at full capability from console directly on my HPC sever (ie. without a display server). With VS Code I think I would need to use another device to ssh into the server.
        deafpolygon 3y ago
        If you are wanting to edit files remotely, you can do so with: - https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview - https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh
        medo-bear 3y ago
        Thats what I said. Emacs gives me the option to edit on the machine through tty. You just can not do this on VS Code
sdumi 3y ago
I have to give a +1 on this article. I'm not a big mouse gesture fan or user but I do agree with the mindset to use best tool available for the task. What 'best' means is subjective but I like discovering new tools or options I didn't know I have. Thanks!
abdullahkhalids 3y ago
When I started using emacs about 15 years ago, I turned off all possible mouse interactions in my config, to force myself to learn and use the keyboard efficiently. A few months ago, I redid my emacs config, and decided to allow mouse interaction again. Honestly, besides occasionally scrolling in a long document, I haven't felt the need to use the mouse at all. The keyboard just works.
- elygre 3y ago
  Yes, but also «after 15 years of practice, the keyboard just works”
- hollerith 3y ago
  Huh. My experience was very different. I didn't gain the ability to use the mouse to interact with Emacs till 2010 because before then graphical Emacs on Linux had bit-mapped text that I hated to look at (the main issue's being that it clashed horribly with the text in all the other apps I was using, including my browser). When text rendering in graphical Emacs improved and I started being able to use the mouse in Emacs, I realized I had made a big mistake in not taking the trouble to acquire the ability to use the mouse in Emacs earlier: the MacOS port (called "Carbon Emacs" IIRC) had had satisfactory text rendering (and mouse support) for many years and even if I wanted to avoid switching to a Mac, I could have switched to graphical Emacs years earlier if I was willing to compile Emacs from source (and setting a flag to choose the GTK front end, not to be confused with the more recent PGTK front end). The point is that I regret letting myself be influenced by the comments on this site to the effect that the pointing device is unimportant. (Also, in a survey of Emacs users a few years ago, 80% report using graphical Emacs rather than using Emacs via a terminal interface.)
  - jrockway 3y ago
    M-x xterm-mouse-mode was what you wanted pre-2010. I still run Emacs in the terminal (Windows desktop -> Linux VM for coding... don't ask).
    - deleted 3y ago
mbork_pl 3y ago
> Test subjects consistently report that keyboarding is faster than mousing. > The stopwatch consistently proves mousing is faster than keyboarding. I like to think that the goal of optimizing my editing workflow is not (necessarily) making it objectively faster, but rather making it feel faster so that the frustrations are removed and the experience is smoother. This is, of course, my entirely subjective take.
- xeyownt 3y ago
  I guess this is again a case of taking the results of a study to pull conclusions in different contexts.
- merelysounds 3y ago
  Same. The article describes friction and reducing context switching - I agree with that too. In practice: if, while in deep focus, I can e.g. navigate the project via muscle memory, this means I can keep thinking about the problem domain. As opposed to pausing to hunt and peck an icon or a token.
  - troupo 3y ago
    While in deep focus I use the mouse extensively because I can scroll text, quickly Cmd/Ctrl-click on code that is far away from the cursor etc. Note: I use IntelliJ IDEA that has full keyboard navigation and mouse navigation.
    - klibertp 3y ago
      Scrolling is indeed one of the things that both are and feel faster with the mouse. I also came to like docs popping up on mouse hover (in IDEA and with lsp-ui in Emacs), as well as "go to definition" on C-<mouse-1>. The context menu on right-click (see mouse3.el for Emacs) is also helpful when browsing/reading the code. When coding, reaching for the mouse is an irritating distraction. When reading, though, if you have enough actions bound to the mouse, I find mousing to be much more convenient. Mainly because I can eat my sandwich with one hand while still navigating and making minor changes with the other hand. Many mice and trackballs (my preference) offer just enough distinct buttons/events to bind almost everything you'd need to do during a review of some code, for example. Default bindings for the mouse in Emacs are all wrong for this - most useful things are bound to C/M-<mouse-x>, and pressing C or M with a hand holding a sandwich is neither convenient nor hygienic. I'm now trying to remap the useful things so that they are accessible with only a mouse.
fgoesbrrr 3y ago
Today mouse is 2 different things: actual mouse or trackpad.
- sping 3y ago
  It's mostly the TrackPoint for me, and I've worked with quite a few trackball users.
  - rgoulter 3y ago
    You can distinguish a trackpad from a mouse, in that stuff like "multi-finger gestures" or "pinch in/out" makes sense on a trackpad but not a mouse. Whereas, a trackball is roughly the same as a mouse. (Albeit, much more comfortable to use, IMO).
pmontra 3y ago
Some of those mouse (touchpad for me) gestures could be useful, like splitting a buffer in two. If it's the current buffer, C-x 2 and C-x 3 feel faster. If it's another one probably the gesture is faster. They are also easy to remember. Some other gestures are puzzling, like > Middle click to paste a link from the clipboard. (This is only for clarity, it’s unrelated to the actual action.) Then use a mouse gesture to git-clone from that link to a prespecified directory. I wonder how many times per day one has to clone repositories before one could remember that the gesture for that exists and how to perform it in the right way. It takes training. I clone repositories not every month, maybe I even spent at least one full year without cloning anything (long running projects.) But OK, I'm sure there are people that have to work with many different repositories at least every week.
- eichin 3y ago
  Raskin's version of Tog's point (in the article) is more nuanced - switching between keyboard and mouse is the expensive thing and even more "perceptually underreported" than either of them on their own. (That said, my workflow involves cloning as often as a couple of times a day if things are going well; SSD space is basically free, and --reference-if-able means a clone-per-branch is cheap, and my "work on this" script spins up a docker image and a fresh build too, after cloning and switching. So, while the described shortcuts would make sense in my "world", I've already automated way beyond that :-)
  - pmontra 3y ago
    To test my intuition: as a two-to-five clones per day person, do you think that you could benefit from that gesture, if you didn't need to automate the process around it?
    - eichin 3y ago
      If I were already using the mouse for the cut&paste step, yeah, it would flow from one to the other. (In practice, I do both the cut-whole-url and paste steps entirely from the keyboard anyway, so using a gesture at all would be flow-breaking. But if I were mousing for the surrounding work it would make sense.) (I've actually had mouse-based workflows sometimes - I normally prefer a trackpoint, not as a mouse substitute but as "save me from doing weird contortions to keyboard-orient absolutely everything" - but the times when I've been a tech lead and spending excessive time in spreadsheets and planning apps, I've hooked up a relatively fancy mouse and started to develop more mouse-oriented shortcuts. Fortunately I've escaped from that :-)
ReleaseCandidat 3y ago
Of course I always used a mouse with Emacs, if not I could have used vim.
frou_dh 3y ago
Something that seems to permeate keyboard vs mouse debates is an unsaid assumption that some kind of robotic consistency/purity is the goal. I don't buy that at all when a human being is involved. There are tons of actions I know perfectly well how to achieve with either the keyboard or the mouse, and which of those I unconsciously choose at a given instant varies based on what else I'm thinking about, precisely how I'm physically positioned, and just how I'm feeling. There no problem with that.
- tfinch 3y ago
  exactly this. I've realized recently that (for me) mouse interactions come more naturally for more exploratory or creative work. I'm happy with my mouse! and yet for straight coding, or writing, I would rather keep my hands on the keyboard. It's fun to get good with all the tools(toys)!
drekipus 3y ago
I mouse in vim to either scroll or move the cursor exactly where I'm looking* * Which is often not where I need the cursor to be for some vim commands
- bombela 3y ago
  You mind find easymotion or similar useful. I am really fast and precise with a real mouse. Not so much on a trackpad and trackpoint. Easymotion is a good middle ground.
dfgdfg34545456 3y ago
This is why I always disliked helm. Ivy never forced you to go all in keyboard, and supports the mouse quite well whenever you decide you want to use it.
0x69420 3y ago
mousing is profoundly good if you let it into your life as a programmer, but for me it had the knock-on effect of making programming at a desktop unappealing. i find the ergonomics of alternating between mouse and keyboard that much better on a laptop, whether it's subconsciously just thumbing the trackpad for small motions, or moving my index finger a mere 1.5 keys to the left to smoosh a trackpoint. this must be the impulse behind the yoda and similar[1], but these still don't do it for me: i could not comfortably daily drive anything that solders into a cherry mx footprint, and any mech switches i like would demand a costly, time-consuming from-scratch build. some mac accessory makers have put out a wrist rest that mounts a magic trackpad in front of an apple keyboard, which sounds like it could be really cool adapted to fit a “proper keyboard”, but user testimonies are that the lack of palm rejection drives them nuts. for reference, a trackpad to the right of the keyboard defeats the purpose from my point of view, as if i'm going to perform a whole-arm motion to access a different input device, i may as well have my hand land on my trusty wireless mouse: if it's good enough for getting headshots it's good enough for selecting text, plus i get proper mouse chording, which i must admit to missing over in trackpad land. so, laptop it is. here's hoping my spine doesn't hate me when i'm fifty. [1] https://i.imgur.com/VBk868o.jpeg https://i.imgur.com/VBk868o.jpeg
- crashmat 3y ago
  There are also some ergonomic split keyboards with a trackball or trackpad to the bottom left of the right keyboard to be used with the thumb like the UHK v2
  - necrotic_comp 3y ago
    There's also the Tex Shinobi, which I've been using for a long time now and is the best keyboard I've ever used. https://tex.com.tw/products/shinobi?variant=16969883648090 https://tex.com.tw/products/shinobi?variant=16969883648090
antics9 3y ago
Everyone should try Acme for a month and then go back to your favourite editor. http://acme.cat-v.org/ http://acme.cat-v.org/
- 0x69420 3y ago
  the article does mention it toward the end. when i was 18 i tried it out half in jest thinking the people pushing it were just being contrarian... i'm 26 now and cannot imagine life without it
  - oblio 3y ago
    The problem with stuff like this is: sure, maybe it's amazing. Then what do you do with it? Is the UI reproduced anywhere else? Does it have LSP/intellisense support? Can it be automated through various means, such as macros? Etc.
    - confd 3y ago
      A Tour of Acme: http://research.swtch.com/acme http://research.swtch.com/acme If you need to do anything aside from what this video suggests acme is capable of, do it with something else.
      - crabbone 3y ago
        Thanks for the link. Some bits are nice, like, for instance, exposing editor's internal state as a filesystem to make it easy to automate by external tools. Unfortunately, like with the similar ideas (i.e. sysfs, procfs), time showed this is a bad idea. Well, it's not bad for simple things, but it hits a hard ceiling that requires completely dropping this concept in favor of something more robust. On the count of scrolling and moving windows around... when I have to deal with new programmers, no matter what editor they use, one of the biggest productivity tips is to learn to never scroll and never move windows around, resize them etc. Doing so you learn to work hard, imprecisely, and blur your focus on inconsequential things. The way to move around structured text (eg. code) is to either move by structure, or by search, or through something like "ace jump" -- learning this habit makes you work with more precision and less distraction. Similarly, with moving windows around / changing layout. Depending on the shape of your screen there's really only ever going to be one best window layout. Usually, it's something simple, like two windows side by side, or one on top of another if you use a vertical screen etc. Trying to modify that always leads to both waste of time and loss of focus. It's best to develop the habit of bringing the desired content into the window with set dimensions than to manipulate window sizes and positions. Predictable layout also allows for easier design on ad hoc functionality that responds to events in one window in another. Finally, some bits are trivial (at least in Emacs), all that executing commands from text extensively covered by the video is C-! or C-| in Emacs. My experience with these shows that in practice they are almost never enough, and what I need is something like Org code blocks with variables, rendering information etc. So, again, it looks nice, but falls apart once more robust functionality is desired. Plumber is also a nice idea, and, I believe Emacs has something similar to it, the thing-at-point and some other functionality derived from it. But, I'm not sure what's the current state of this functionality. Finally, an anecdote about clicking with mouse (an actual horror story I went through). The older Jenkins interface had "Delete Job" button right under "Run Job". It also used to be common to rely on Jenkins to store build artifacts (those were simpler times...) So, one day I was summoned to the office due to an emergency caused by a developer who wanted to run a release build, but accidentally fat-fingered into clicking the "Delete Job" button and wiped not only the job, but also the associated workspace that contained all builds so far. Some recent versions were forever lost that day due to backups being done once every few days or so. Anyways, the moral of the story: opening or executing files by pressing mouse button -- I would never do that. Just an all around awful idea. Very easy to do a lot of damage just by accidentally hitting your funny bone or by sneezing etc.
klibertp 3y ago
Related: https://danluu.com/keyboard-v-mouse/ https://danluu.com/keyboard-v-mouse/ - "The widely cited studies on mouse vs. keyboard efficiency are completely bogus." EDIT: More on topic: I tried, but the percentage of times when my stroke wasn't recognized was way too high for me. There's a customization variable that could help, but I have enough programmable buttons on my physical mouse[1] to get by with just them: - scroll up/down - tilt wheel left/right - two small buttons for back/forward to the left of the left button - dpi change button under thumb (can be made to send other events with Solaar) So I can directly bind 5-7 commands that will work every time without risking the "stroke was not recognized" problem. And that's without modifiers and clever hacks like mouse3.el, which allow for (almost) directly exposing even more functionality. Strokes/gestures are slower and less reliable than this. They probably can be helpful in some configurations (I wonder if Emacs on Android would be the perfect use case?), but I don't feel the need for them in my setup. [1] https://www.logitech.com/en-us/products/mice/mx-ergo-wireless-trackball-mouse.html https://www.logitech.com/en-us/products/mice/mx-ergo-wireles...
- bloopernova 3y ago
  For an even more configurable mouse, check out the Ploopy mouse and trackballs: https://ploopy.co/ https://ploopy.co/ Fully open source, the mouse (that I own) uses QMK for its firmware. Which means I can use key binding layers rather than single buttons. In other words, one button acts like a shift button that modifies the action of the other buttons. So I have easy access to page up/down, mission control (what was exposé in macOS), paste plain (shift+option+cmd+v), etc etc. I don't have anything Emacs specific on the mouse, but my keyboard (Keychron Q10) has several macro keys that I have meta-x and ctrl-g bound to.
  - m463 3y ago
    strange. It is 3d-printed and fully customizable, but they only have right-handed. even the pcb seems to be right-handed.
  - deafpolygon 3y ago
    At 200+ euros, it puts a high barrier for entry. I might try it someday when I have more money, but I have other pressing things to buy first. :(
g-b-r 3y ago
As others already hinted at, pretty much all the arguments against using the mouse for some things break down when you have a touchpad. In most cases windows resizing, moving and usually selecting and scrolling (with chiral scrolling) are faster and more convenient by an order of magnitude. And reaching out to a (central) touchpad takes about as much effort as reaching any keyboard key. People should really give them a chance; unfortunately many are mislead by the Emacs and Vim's docs, but when they were written touchpads didn't even exist.
- yura 3y ago
  > People should really give them a chance; unfortunately many are mislead by the Emacs and Vim's docs, but when they were written touchpads didn't even exist. Emacs's docs are updated constantly, up to this day. And in there are mentioned both "touchpad" (5 hits) and "mouse" (660 hits).
  - g-b-r 3y ago
    Of course, but some things persist. I actually realized that the current Emacs docs have less old cruft than they used to (e.g. about the meta/alt thing). I should have said docs, guides and articles anyhow (which were not written before the invention of touchpads but usually carry on the keyboard-exclusively myths).
    - oblio 3y ago
      > I actually realized that the current Emacs docs have less old cruft than they used to (e.g. about the meta/alt thing). Could you please expand on this?
  - oblio 3y ago
    > Emacs's docs are updated constantly, up to this day. And in there are mentioned both "touchpad" (5 hits) and "mouse" (660 hits). Have they updated just some simple references or the spirit of the docs?
- gpderetta 3y ago
fsloth 3y ago
I love this quote so much: ” 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. – Bruce Tognazzini ” The question one needs to ask from oneself - am I a poweruser or do I just enjoy yak shaving. I used to configure everything ”so it’s exactly right for me”. At some point I switched to mostly using default options for everything, and if given the option, choosing what ever had best default options (for myself). I like my computer use much more nowadays as stuff tends to ”just work” and I can focus on actually just doing stuff.
- orzig 3y ago
  Great quote, I bet it was very true in 1989 (34 years ago!) I'm not going to try to prove the opposite, but after some number of DECADES it's worth checking on followup research. Here are some good places to start: https://ux.stackexchange.com/questions/30682/are-there-any-recent-studies-of-the-keyboard-vs-mouse-issue https://ux.stackexchange.com/questions/30682/are-there-any-r... https://skeptics.stackexchange.com/questions/4355/is-using-a-mouse-less-efficient https://skeptics.stackexchange.com/questions/4355/is-using-a...
  - froh 3y ago
    thanks! and the Sceptics SO circles back here in 2011: https://news.ycombinator.com/item?id=2657135 https://news.ycombinator.com/item?id=2657135 the keyboard vs mouse controversy is an evergreen
- iLemming 3y ago
  > and I can focus on actually just doing stuff. Why people love blaming Emacsians for having an obsession with configuring everything "so things are exactly right for them", I will never understand. It's not about configuring for the sake of configuring. It may feel that way in the beginning, but after a while, it becomes simple to make stuff "just work," as you say. Take this simple case of dealing with URLs, for example. I share tons of URLs with my colleagues, and I have to consume tons of URLs shared with me. Every single day. So, I have a way of sharing the exact places in the code. What it does is it figures out all the relevant information: - The repo - The Git branch - Fully qualified name of a function or a line number And then it creates a Markdown Link with a description and the exact place on GitHub for that line of code. It takes me a single keystroke to share that with my teammate and I don't even have to leave my editor. My teammates may not bother with doing the same thing manually. They would just share a link without a description. And when the URL looks something like: https://github.com/foo/bar/blob/fbf7e86b8e8372e460af5a283c05f8caf9cbd0c7/blabla/yadayda/file.clj#L11 https://github.com/foo/bar/blob/fbf7e86b8e8372e460af5a283c05... it's impossible to tell what that thing is about without opening it in the browser. Well, again using a single keystroke, I can convert it to Org-Mode or Markdown. It goes to GitHub, logs in using my token (because it's in a private repo), and figures out what that thing exactly is, giving me a URL with a description. I can store it in my notes and search for it later. So the question you really need to ask yourself - are you a power user or a programmer? I am the latter, so I don't feel that writing code that makes the computer do exactly what I meant it to do is a waste of time. I write code so I can focus on actually doing stuff. And if I need to spend an hour to write some code that makes me just 0.01% more efficient, well, fuck it, why not?
MantisShrimp90 3y ago
This doesn't resonate with me because I grew up with mouse and gesture support and I left for a reason. Now I guess I need to say this, if you find yourself intimidated or put-off by keyboard-centric workflows THATS FINE. I think the real problem is we assume that keyboard workflows are necessary for mastery, especially when we first start, and so people get all defensive about not jumping into vim/emacs. On the flip side, if you did embrace this way of life and actually do look down on people who don't, stop, you're making it harder for everyone and giving us keyboard warriors a bad name. I got the bug after years of playing sc2. It gave me an innate sense for how to do a series of actions quickly and mechanically while leaving my mind free to do more strategic thinking. I just can't get enough of this mindset which is why I try to cram it into every app I can. But I'm having to come to terms with the fact that new generations of programmers don't know how to touch type, let alone adopt emacs or neovim. Hell, people are starting to use chatgpt to just yell at their computer to create code with their damn voice, which would make keyboard-centric workflows akin to writing in cursive, an overly-specialized skill that will be seen as increasingly obsolete as new forms of communication overtake them. I won't lie, that makes me sad on a level, but it would be unrealistic of me to expect others to go through the same training I did when it simply isn't as relevant to their lives.
silent_cal 3y ago
The real question is, does the quickness of using the keyboard alone make up for all the time you've spent learning emacs
iLemming 3y ago
One pretty neat Emacs trick is to bind mouse click events to toggle multiple cursors. Here's for example how to use Ctrl+Mouse_Click with evil-mc (vanilla Emacs equivalent is mc/toggle-cursor-on-click) (with-eval-after-load 'evil-mc (global-set-key (kbd "C-<down-mouse-1>") 'evil-mc-toggle-cursor-on-click)) You would just click, click, click while holding Ctrl and then you can edit a bunch of things simultaneously.
- BaculumMeumEst 3y ago
  do you find that you use that for cases where you wouldn’t use mc/mark-next-like-this or mc/edit-lines? i think i will try it out regardless, thanks
- deafpolygon 3y ago
  You can do this in VS Code, but it's Alt+Click. It's a default binding.
rgoulter 3y ago
In Emacs specifically.. A large part of the emphasis of "keep your hands on the keyboard" is aimed at beginners. Well, at least in the case of Vim bindings. Learning such keybindings has a steep cost; while learning them, it's always going to be more practical to just use a mouse. But, once you learn them, then it's often quicker. For keyboard-driven programs, I'd say a (well-configured) Emacs is the gold standard. OP makes the suggestion that using the "strokes" package functionality will have some advantages over keyboard binding. -- If it works for the user, sure. But, I'd worry about stroke recognition.. and it doesn't seem to me that memorizing a mouse stroke is going to be easier than memorising some key sequence. In Emacs, if there's some command I want to run, I'll invoke the "execute-command" with "SPC-:", find the command, then look at the keybinding next to that so I can rehearse using the keybinding.
brlewis 3y ago
Contrary to what the Dan Luu article says, I see a very specific detail from Bruce Tognazzini that takes the mystery out of the claim that $50MM in research says the mouse is faster. Once you go past the expired certificate warning you can see it too at https://www.asktog.com/TOI/toi06KeyboardVMouse1.html https://www.asktog.com/TOI/toi06KeyboardVMouse1.html It's in the context of inconsistent keybindings across different apps, and the pertinent detail is, "It takes two seconds to decide upon which special-function key to press". Contexts where you instantly know the keys to press are different from what the $50MM research studied.
mathgradthrow 3y ago
I'm suspicious of anyone who claims to be meaningfully limited by their typing speed in any task but data entry.
- bee_rider 3y ago
  Concern about typing speed is a devastating indictment of your programming language of choice, haha.
bee_rider 3y ago
> Even so, I use the mouse frequently because it’s often the best way to select text, images and links, do graphical work, and to interact with (both simple and complex) GUI software. “Select text” seems (IMO) like something where these microbenchmarks have an obvious flaw. If you set up an artificial test like select a continuous line of text from an arbitrarily formatted file, the mouse might be better. But we’re programmers, right? We make our code nice and tidy. Usually I want to select a whole line in a file that has line numbers. So for line 10, 10ggyy in vim. That’s pretty quick. Or I want to select the first couple columns of multiple rows. Ctrl-v, repeat j as many times as you’d like. I actually have no idea how to do that with a mouse. Anything more complicated, I begin to wonder if we want a macro, find-replace, or something else. A mouse might be better for interacting with GUIs and images but those things simply shouldn’t be done. Text is the correct way to communicate.
- dingnuts 3y ago
  "text is the correct way to communicate" better call your mom and tell her to replace all your baby photos with textual descriptions since those are the "correct" way to communicate and one simply should not interact with images ... if the comment I'm replying to was sarcasm, it went completely over my head. Poe's Law applies here for sure.
  - bee_rider 3y ago
    It is a half-joke. In the sense that it is something I basically believe, but stated in a way that neglects nuance to the degree to which it might tip over into false-ness. Baby pictures, I don’t think they communicate much. They evoke feelings that are already in the mind of the viewer. I mean, it is basically a universal experience, to be shown pictures of other people’s kids and nod along understanding that they are justifiably excited about the objectively boring things their kids are doing, right? This is because they are excited about the ongoing journey that picture acts as a landmark for, which we aren’t a part of. So, I suppose there must an example of an image that communicates something useful out there, somewhere, but the two of us haven’t found it yet.
crabbone 3y ago
> Window selection is a natural extension of basic mouse usage. Resizing windows is a snap. I don't think I can remember the last time I needed to resize a window in Emacs. I think. Also selecting window with a mouse simply would never work for me, because I need to select them by title in most cases. This claim OP makes is just absurd. If OP was honest, then they'd wrote "in some very special and simple cases, which don't happen in practice" using mouse for selecting and resizing windows may be faster." Which doesn't have the same ring to it, obviously. > and drag and drop support I don't feel like I'm missing something if I don't have this feature. Whenever I'm faced with this feature in other programs, I'm very much annoyed I cannot accomplish the action associated with this interface in a different way (unless performing the action precisely is somehow rewarded, as in maybe it's a part of the game where you have to prove you can do things very precisely) > are very intuitive I don't care. The point of using professional tools is that you learn and practice how to use them. Intuitive is for buy-in, it's not for being good at. > The stopwatch consistently proves mousing is faster than keyboarding. Did this measurement incorporate precision? I seriously doubt that. Most importantly, mouse is only a solution for things that are or can be made visible on the screen, and it also requires paying attention to what's going on on the screen. You cannot use your mouse while at the same time looking away from the screen (which I often do), or by trying to access functionality that isn't already on the screen (which is very often what I need to do, like, accessing a particular buffer, or calling a particular command). In fact, mouse is so rarely a solution for anything I need to do during editing that even if it was faster for a very few things it can do, I still wouldn't care because I'd value uniformity of interface over negligible speedups in very few cases.
- crabbone 3y ago
  Also: > When working on something that involves Emacs and one of these mouse driven applications, having to move over to the keyboard for the Emacs bit is exactly the friction we’d like to avoid. This is some cooked-up case. No. This isn't needed. No, I don't feel like I need to botcher the way I use Emacs because I also like to play video games or do some digital drawing every now and then. There's absolutely no need for that. All the cases OP describes already work well without needing a mouse, or are just worthless. For example, when you want to clone a Git repository, you need to either set the current directory appropriately, or specify the directory you want to clone it to. In either case you'd be dealing with Emacs navigation in your preferred way, which would be the bulk of work necessary to accomplish the action. Then pasting something like a link to a Git repository is just one keypress (eg. Shift+Ins) and you are done. Basically, someone got excited about Strokes library, even though it doesn't do anything useful. Maybe it was fun to write, or fun to theorize about how it could be useful in some counterfactual world... but, in reality, I'd never use that and wouldn't feel like I'm missing it, even after I've learned that such a thing exists and what it does.
jrm4 3y ago
All makes sense; I went all in on the "no mouse" idea for a while and eventually came back. I suspect that, despite it all, there's something very useful about being able to see a bit of text and to physically "go to it" like one might with a pen or a highlighter, that for many has less overhead than trying to "think your way towards describing where it is?"
- floren 3y ago
  Sometimes you just want to point at something -- so use the pointing device!
pilgrim0 3y ago
I’ve been studying this for my research. The current conclusion so far, related to perception of flow, is that with keyboard interactions, you’re consistently and progressively closer to your goal. As for the mouse, regardless of timing to achieve the goal, there’s generally a lot of waste, that is, the energy spent does not reflect a step towards the intended goal, because you are moving into space generically and non-deterministically. Mouse interactions are prone to failure/cancellation, since the goal is achieved only at the last instant, one diversion and you are back to square one. Hence the class of actions that must be faster on the mouse are the ones where the goal is immediately and progressively achieved by spatial input, such as scrolling, drawing, etc. since energy is directly translated into effects. Mouse is obviously suited for continuous input, and keyboard for discrete inputs. For all classes of actions apt to be broken into discrete steps, keyboard control will provide consistent and reproducible results. Further, those chunks can be optimized and compressed with mnemonics, whereas mouse actions cannot be compressed. There’s no one versus the other, as both devices are complimentary. With that said, performing discrete interactions with the mouse is a poor use of the tool, regardless of anyone’s preferences. That’s a fact.
NelsonMinar 3y ago
It's 2023 and people are still arguing about whether they should use a 1960s UI technology with emacs or if the 1902 keyboard + teletype interface is enough.
globular-toast 3y ago
It's not about keyboard vs mouse. The most important thing is that you use both hands. Imagine how crap and limited you would be playing the piano with one hand. All keyboard use is assumed to be using two hands. The slow mouse usage is when you just use the mouse and leave the other hand quite literally on the table. But combined keyboard and mouse usage is by far the fastest way to do certain things. I'm not sure text editing is one of them, though.

145 points by signa11 3y ago

The magic of Emacs is that you can set it up the way you like. On mousing, it depends. Faster in some cases for making changes on editing and browsing the web in eww if you don't care about ctrl-s.

oblio 3y ago
> The magic of Emacs is that you can set it up the way you like. Can you set it up to: 1. have tabs (like in Vim) 2. have the command bar/line/whatever it's called at the top ? :-)
- klibertp 3y ago
  Tabs are built-in from a few versions, see https://www.gnu.org/software/emacs/manual/html_node/emacs/Tab-Bars.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Ta... > have the command bar/line/whatever it's called at the top I think what you mean is called a mode-line: https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Mo... (or do you mean the thing where you type commands, like C-S-p in VS Code?) To make it display at the top of the buffer window you'd need to repurpose a header line with some custom config. There might be a package for it. Do you have a screenshot of how you'd like it to look like?
  - oblio 3y ago
    VS Code Ctrl-Shift-P, yes. And I'd want the results to drop down not to climb up.
    - klibertp 3y ago
      Very possible, yes: https://github.com/tumashu/vertico-posframe https://github.com/tumashu/vertico-posframe. You can position the box anywhere you want by configuring the parameter: vertico-posframe-poshandler . posframe-poshandler-frame-top-center ^^^^^^^^^^^^^^^^ I use `posframe-poshandler-frame-bottom-center`, which looks like this: https://klibert.pl/statics/vertico-screenshot.png https://klibert.pl/statics/vertico-screenshot.png Those ugly things at the top of the window are tabs - they can look much better if you use a modern theme (personally, it never bothered me enough to put time into configuring them).

medo-bear 3y ago

one of the better emacs+mouse actions for me is rectangle select with C+M+'hold left button and select'

deafpolygon 3y ago
Alt+Shift+Mouse in VS Code
- medo-bear 3y ago
  Can VS Code do this in virtual console or even in terminal?
  - deafpolygon 3y ago
    Yes, Alt+Mouse1, then you can Ctrl+C to copy.
    - medo-bear 3y ago
      As far as I know VS Code only runs within a windowing system, not inside a terminal. On the other hand I can run my Emacs at full capability from console directly on my HPC sever (ie. without a display server). With VS Code I think I would need to use another device to ssh into the server.
      - deafpolygon 3y ago
        If you are wanting to edit files remotely, you can do so with: - https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview - https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh
        medo-bear 3y ago
        Thats what I said. Emacs gives me the option to edit on the machine through tty. You just can not do this on VS Code

sdumi 3y ago

I have to give a +1 on this article. I'm not a big mouse gesture fan or user but I do agree with the mindset to use best tool available for the task. What 'best' means is subjective but I like discovering new tools or options I didn't know I have. Thanks!

abdullahkhalids 3y ago

When I started using emacs about 15 years ago, I turned off all possible mouse interactions in my config, to force myself to learn and use the keyboard efficiently. A few months ago, I redid my emacs config, and decided to allow mouse interaction again. Honestly, besides occasionally scrolling in a long document, I haven't felt the need to use the mouse at all. The keyboard just works.

elygre 3y ago
Yes, but also «after 15 years of practice, the keyboard just works”
hollerith 3y ago
Huh. My experience was very different. I didn't gain the ability to use the mouse to interact with Emacs till 2010 because before then graphical Emacs on Linux had bit-mapped text that I hated to look at (the main issue's being that it clashed horribly with the text in all the other apps I was using, including my browser). When text rendering in graphical Emacs improved and I started being able to use the mouse in Emacs, I realized I had made a big mistake in not taking the trouble to acquire the ability to use the mouse in Emacs earlier: the MacOS port (called "Carbon Emacs" IIRC) had had satisfactory text rendering (and mouse support) for many years and even if I wanted to avoid switching to a Mac, I could have switched to graphical Emacs years earlier if I was willing to compile Emacs from source (and setting a flag to choose the GTK front end, not to be confused with the more recent PGTK front end). The point is that I regret letting myself be influenced by the comments on this site to the effect that the pointing device is unimportant. (Also, in a survey of Emacs users a few years ago, 80% report using graphical Emacs rather than using Emacs via a terminal interface.)
- jrockway 3y ago
  M-x xterm-mouse-mode was what you wanted pre-2010. I still run Emacs in the terminal (Windows desktop -> Linux VM for coding... don't ask).
  - deleted 3y ago

mbork_pl 3y ago

> Test subjects consistently report that keyboarding is faster than mousing. > The stopwatch consistently proves mousing is faster than keyboarding. I like to think that the goal of optimizing my editing workflow is not (necessarily) making it objectively faster, but rather making it feel faster so that the frustrations are removed and the experience is smoother. This is, of course, my entirely subjective take.

xeyownt 3y ago
I guess this is again a case of taking the results of a study to pull conclusions in different contexts.
merelysounds 3y ago
Same. The article describes friction and reducing context switching - I agree with that too. In practice: if, while in deep focus, I can e.g. navigate the project via muscle memory, this means I can keep thinking about the problem domain. As opposed to pausing to hunt and peck an icon or a token.
- troupo 3y ago
  While in deep focus I use the mouse extensively because I can scroll text, quickly Cmd/Ctrl-click on code that is far away from the cursor etc. Note: I use IntelliJ IDEA that has full keyboard navigation and mouse navigation.
  - klibertp 3y ago
    Scrolling is indeed one of the things that both are and feel faster with the mouse. I also came to like docs popping up on mouse hover (in IDEA and with lsp-ui in Emacs), as well as "go to definition" on C-<mouse-1>. The context menu on right-click (see mouse3.el for Emacs) is also helpful when browsing/reading the code. When coding, reaching for the mouse is an irritating distraction. When reading, though, if you have enough actions bound to the mouse, I find mousing to be much more convenient. Mainly because I can eat my sandwich with one hand while still navigating and making minor changes with the other hand. Many mice and trackballs (my preference) offer just enough distinct buttons/events to bind almost everything you'd need to do during a review of some code, for example. Default bindings for the mouse in Emacs are all wrong for this - most useful things are bound to C/M-<mouse-x>, and pressing C or M with a hand holding a sandwich is neither convenient nor hygienic. I'm now trying to remap the useful things so that they are accessible with only a mouse.

fgoesbrrr 3y ago

Today mouse is 2 different things: actual mouse or trackpad.

sping 3y ago
It's mostly the TrackPoint for me, and I've worked with quite a few trackball users.
- rgoulter 3y ago
  You can distinguish a trackpad from a mouse, in that stuff like "multi-finger gestures" or "pinch in/out" makes sense on a trackpad but not a mouse. Whereas, a trackball is roughly the same as a mouse. (Albeit, much more comfortable to use, IMO).

pmontra 3y ago

Some of those mouse (touchpad for me) gestures could be useful, like splitting a buffer in two. If it's the current buffer, C-x 2 and C-x 3 feel faster. If it's another one probably the gesture is faster. They are also easy to remember. Some other gestures are puzzling, like > Middle click to paste a link from the clipboard. (This is only for clarity, it’s unrelated to the actual action.) Then use a mouse gesture to git-clone from that link to a prespecified directory. I wonder how many times per day one has to clone repositories before one could remember that the gesture for that exists and how to perform it in the right way. It takes training. I clone repositories not every month, maybe I even spent at least one full year without cloning anything (long running projects.) But OK, I'm sure there are people that have to work with many different repositories at least every week.

eichin 3y ago
Raskin's version of Tog's point (in the article) is more nuanced - switching between keyboard and mouse is the expensive thing and even more "perceptually underreported" than either of them on their own. (That said, my workflow involves cloning as often as a couple of times a day if things are going well; SSD space is basically free, and --reference-if-able means a clone-per-branch is cheap, and my "work on this" script spins up a docker image and a fresh build too, after cloning and switching. So, while the described shortcuts would make sense in my "world", I've already automated way beyond that :-)
- pmontra 3y ago
  To test my intuition: as a two-to-five clones per day person, do you think that you could benefit from that gesture, if you didn't need to automate the process around it?
  - eichin 3y ago
    If I were already using the mouse for the cut&paste step, yeah, it would flow from one to the other. (In practice, I do both the cut-whole-url and paste steps entirely from the keyboard anyway, so using a gesture at all would be flow-breaking. But if I were mousing for the surrounding work it would make sense.) (I've actually had mouse-based workflows sometimes - I normally prefer a trackpoint, not as a mouse substitute but as "save me from doing weird contortions to keyboard-orient absolutely everything" - but the times when I've been a tech lead and spending excessive time in spreadsheets and planning apps, I've hooked up a relatively fancy mouse and started to develop more mouse-oriented shortcuts. Fortunately I've escaped from that :-)

ReleaseCandidat 3y ago

Of course I always used a mouse with Emacs, if not I could have used vim.

frou_dh 3y ago

Something that seems to permeate keyboard vs mouse debates is an unsaid assumption that some kind of robotic consistency/purity is the goal. I don't buy that at all when a human being is involved. There are tons of actions I know perfectly well how to achieve with either the keyboard or the mouse, and which of those I unconsciously choose at a given instant varies based on what else I'm thinking about, precisely how I'm physically positioned, and just how I'm feeling. There no problem with that.

tfinch 3y ago
exactly this. I've realized recently that (for me) mouse interactions come more naturally for more exploratory or creative work. I'm happy with my mouse! and yet for straight coding, or writing, I would rather keep my hands on the keyboard. It's fun to get good with all the tools(toys)!

drekipus 3y ago

I mouse in vim to either scroll or move the cursor exactly where I'm looking* * Which is often not where I need the cursor to be for some vim commands

bombela 3y ago
You mind find easymotion or similar useful. I am really fast and precise with a real mouse. Not so much on a trackpad and trackpoint. Easymotion is a good middle ground.

dfgdfg34545456 3y ago

This is why I always disliked helm. Ivy never forced you to go all in keyboard, and supports the mouse quite well whenever you decide you want to use it.

0x69420 3y ago

mousing is profoundly good if you let it into your life as a programmer, but for me it had the knock-on effect of making programming at a desktop unappealing. i find the ergonomics of alternating between mouse and keyboard that much better on a laptop, whether it's subconsciously just thumbing the trackpad for small motions, or moving my index finger a mere 1.5 keys to the left to smoosh a trackpoint. this must be the impulse behind the yoda and similar[1], but these still don't do it for me: i could not comfortably daily drive anything that solders into a cherry mx footprint, and any mech switches i like would demand a costly, time-consuming from-scratch build. some mac accessory makers have put out a wrist rest that mounts a magic trackpad in front of an apple keyboard, which sounds like it could be really cool adapted to fit a “proper keyboard”, but user testimonies are that the lack of palm rejection drives them nuts. for reference, a trackpad to the right of the keyboard defeats the purpose from my point of view, as if i'm going to perform a whole-arm motion to access a different input device, i may as well have my hand land on my trusty wireless mouse: if it's good enough for getting headshots it's good enough for selecting text, plus i get proper mouse chording, which i must admit to missing over in trackpad land. so, laptop it is. here's hoping my spine doesn't hate me when i'm fifty. [1] https://i.imgur.com/VBk868o.jpeg https://i.imgur.com/VBk868o.jpeg

crashmat 3y ago
There are also some ergonomic split keyboards with a trackball or trackpad to the bottom left of the right keyboard to be used with the thumb like the UHK v2
- necrotic_comp 3y ago
  There's also the Tex Shinobi, which I've been using for a long time now and is the best keyboard I've ever used. https://tex.com.tw/products/shinobi?variant=16969883648090 https://tex.com.tw/products/shinobi?variant=16969883648090

antics9 3y ago

Everyone should try Acme for a month and then go back to your favourite editor. http://acme.cat-v.org/ http://acme.cat-v.org/

0x69420 3y ago
the article does mention it toward the end. when i was 18 i tried it out half in jest thinking the people pushing it were just being contrarian... i'm 26 now and cannot imagine life without it
- oblio 3y ago
  The problem with stuff like this is: sure, maybe it's amazing. Then what do you do with it? Is the UI reproduced anywhere else? Does it have LSP/intellisense support? Can it be automated through various means, such as macros? Etc.
  - confd 3y ago
    A Tour of Acme: http://research.swtch.com/acme http://research.swtch.com/acme If you need to do anything aside from what this video suggests acme is capable of, do it with something else.
    - crabbone 3y ago
      Thanks for the link. Some bits are nice, like, for instance, exposing editor's internal state as a filesystem to make it easy to automate by external tools. Unfortunately, like with the similar ideas (i.e. sysfs, procfs), time showed this is a bad idea. Well, it's not bad for simple things, but it hits a hard ceiling that requires completely dropping this concept in favor of something more robust. On the count of scrolling and moving windows around... when I have to deal with new programmers, no matter what editor they use, one of the biggest productivity tips is to learn to never scroll and never move windows around, resize them etc. Doing so you learn to work hard, imprecisely, and blur your focus on inconsequential things. The way to move around structured text (eg. code) is to either move by structure, or by search, or through something like "ace jump" -- learning this habit makes you work with more precision and less distraction. Similarly, with moving windows around / changing layout. Depending on the shape of your screen there's really only ever going to be one best window layout. Usually, it's something simple, like two windows side by side, or one on top of another if you use a vertical screen etc. Trying to modify that always leads to both waste of time and loss of focus. It's best to develop the habit of bringing the desired content into the window with set dimensions than to manipulate window sizes and positions. Predictable layout also allows for easier design on ad hoc functionality that responds to events in one window in another. Finally, some bits are trivial (at least in Emacs), all that executing commands from text extensively covered by the video is C-! or C-| in Emacs. My experience with these shows that in practice they are almost never enough, and what I need is something like Org code blocks with variables, rendering information etc. So, again, it looks nice, but falls apart once more robust functionality is desired. Plumber is also a nice idea, and, I believe Emacs has something similar to it, the thing-at-point and some other functionality derived from it. But, I'm not sure what's the current state of this functionality. Finally, an anecdote about clicking with mouse (an actual horror story I went through). The older Jenkins interface had "Delete Job" button right under "Run Job". It also used to be common to rely on Jenkins to store build artifacts (those were simpler times...) So, one day I was summoned to the office due to an emergency caused by a developer who wanted to run a release build, but accidentally fat-fingered into clicking the "Delete Job" button and wiped not only the job, but also the associated workspace that contained all builds so far. Some recent versions were forever lost that day due to backups being done once every few days or so. Anyways, the moral of the story: opening or executing files by pressing mouse button -- I would never do that. Just an all around awful idea. Very easy to do a lot of damage just by accidentally hitting your funny bone or by sneezing etc.

klibertp 3y ago

Related: https://danluu.com/keyboard-v-mouse/ https://danluu.com/keyboard-v-mouse/ - "The widely cited studies on mouse vs. keyboard efficiency are completely bogus." EDIT: More on topic: I tried, but the percentage of times when my stroke wasn't recognized was way too high for me. There's a customization variable that could help, but I have enough programmable buttons on my physical mouse[1] to get by with just them: - scroll up/down - tilt wheel left/right - two small buttons for back/forward to the left of the left button - dpi change button under thumb (can be made to send other events with Solaar) So I can directly bind 5-7 commands that will work every time without risking the "stroke was not recognized" problem. And that's without modifiers and clever hacks like mouse3.el, which allow for (almost) directly exposing even more functionality. Strokes/gestures are slower and less reliable than this. They probably can be helpful in some configurations (I wonder if Emacs on Android would be the perfect use case?), but I don't feel the need for them in my setup. [1] https://www.logitech.com/en-us/products/mice/mx-ergo-wireless-trackball-mouse.html https://www.logitech.com/en-us/products/mice/mx-ergo-wireles...

bloopernova 3y ago
For an even more configurable mouse, check out the Ploopy mouse and trackballs: https://ploopy.co/ https://ploopy.co/ Fully open source, the mouse (that I own) uses QMK for its firmware. Which means I can use key binding layers rather than single buttons. In other words, one button acts like a shift button that modifies the action of the other buttons. So I have easy access to page up/down, mission control (what was exposé in macOS), paste plain (shift+option+cmd+v), etc etc. I don't have anything Emacs specific on the mouse, but my keyboard (Keychron Q10) has several macro keys that I have meta-x and ctrl-g bound to.
- m463 3y ago
  strange. It is 3d-printed and fully customizable, but they only have right-handed. even the pcb seems to be right-handed.
- deafpolygon 3y ago
  At 200+ euros, it puts a high barrier for entry. I might try it someday when I have more money, but I have other pressing things to buy first. :(

g-b-r 3y ago

As others already hinted at, pretty much all the arguments against using the mouse for some things break down when you have a touchpad. In most cases windows resizing, moving and usually selecting and scrolling (with chiral scrolling) are faster and more convenient by an order of magnitude. And reaching out to a (central) touchpad takes about as much effort as reaching any keyboard key. People should really give them a chance; unfortunately many are mislead by the Emacs and Vim's docs, but when they were written touchpads didn't even exist.

yura 3y ago
> People should really give them a chance; unfortunately many are mislead by the Emacs and Vim's docs, but when they were written touchpads didn't even exist. Emacs's docs are updated constantly, up to this day. And in there are mentioned both "touchpad" (5 hits) and "mouse" (660 hits).
- g-b-r 3y ago
  Of course, but some things persist. I actually realized that the current Emacs docs have less old cruft than they used to (e.g. about the meta/alt thing). I should have said docs, guides and articles anyhow (which were not written before the invention of touchpads but usually carry on the keyboard-exclusively myths).
  - oblio 3y ago
    > I actually realized that the current Emacs docs have less old cruft than they used to (e.g. about the meta/alt thing). Could you please expand on this?
- oblio 3y ago
  > Emacs's docs are updated constantly, up to this day. And in there are mentioned both "touchpad" (5 hits) and "mouse" (660 hits). Have they updated just some simple references or the spirit of the docs?
gpderetta 3y ago

fsloth 3y ago

I love this quote so much: ” 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. – Bruce Tognazzini ” The question one needs to ask from oneself - am I a poweruser or do I just enjoy yak shaving. I used to configure everything ”so it’s exactly right for me”. At some point I switched to mostly using default options for everything, and if given the option, choosing what ever had best default options (for myself). I like my computer use much more nowadays as stuff tends to ”just work” and I can focus on actually just doing stuff.

orzig 3y ago
Great quote, I bet it was very true in 1989 (34 years ago!) I'm not going to try to prove the opposite, but after some number of DECADES it's worth checking on followup research. Here are some good places to start: https://ux.stackexchange.com/questions/30682/are-there-any-recent-studies-of-the-keyboard-vs-mouse-issue https://ux.stackexchange.com/questions/30682/are-there-any-r... https://skeptics.stackexchange.com/questions/4355/is-using-a-mouse-less-efficient https://skeptics.stackexchange.com/questions/4355/is-using-a...
- froh 3y ago
  thanks! and the Sceptics SO circles back here in 2011: https://news.ycombinator.com/item?id=2657135 https://news.ycombinator.com/item?id=2657135 the keyboard vs mouse controversy is an evergreen
iLemming 3y ago
> and I can focus on actually just doing stuff. Why people love blaming Emacsians for having an obsession with configuring everything "so things are exactly right for them", I will never understand. It's not about configuring for the sake of configuring. It may feel that way in the beginning, but after a while, it becomes simple to make stuff "just work," as you say. Take this simple case of dealing with URLs, for example. I share tons of URLs with my colleagues, and I have to consume tons of URLs shared with me. Every single day. So, I have a way of sharing the exact places in the code. What it does is it figures out all the relevant information: - The repo - The Git branch - Fully qualified name of a function or a line number And then it creates a Markdown Link with a description and the exact place on GitHub for that line of code. It takes me a single keystroke to share that with my teammate and I don't even have to leave my editor. My teammates may not bother with doing the same thing manually. They would just share a link without a description. And when the URL looks something like: https://github.com/foo/bar/blob/fbf7e86b8e8372e460af5a283c05f8caf9cbd0c7/blabla/yadayda/file.clj#L11 https://github.com/foo/bar/blob/fbf7e86b8e8372e460af5a283c05... it's impossible to tell what that thing is about without opening it in the browser. Well, again using a single keystroke, I can convert it to Org-Mode or Markdown. It goes to GitHub, logs in using my token (because it's in a private repo), and figures out what that thing exactly is, giving me a URL with a description. I can store it in my notes and search for it later. So the question you really need to ask yourself - are you a power user or a programmer? I am the latter, so I don't feel that writing code that makes the computer do exactly what I meant it to do is a waste of time. I write code so I can focus on actually doing stuff. And if I need to spend an hour to write some code that makes me just 0.01% more efficient, well, fuck it, why not?

MantisShrimp90 3y ago

This doesn't resonate with me because I grew up with mouse and gesture support and I left for a reason. Now I guess I need to say this, if you find yourself intimidated or put-off by keyboard-centric workflows THATS FINE. I think the real problem is we assume that keyboard workflows are necessary for mastery, especially when we first start, and so people get all defensive about not jumping into vim/emacs. On the flip side, if you did embrace this way of life and actually do look down on people who don't, stop, you're making it harder for everyone and giving us keyboard warriors a bad name. I got the bug after years of playing sc2. It gave me an innate sense for how to do a series of actions quickly and mechanically while leaving my mind free to do more strategic thinking. I just can't get enough of this mindset which is why I try to cram it into every app I can. But I'm having to come to terms with the fact that new generations of programmers don't know how to touch type, let alone adopt emacs or neovim. Hell, people are starting to use chatgpt to just yell at their computer to create code with their damn voice, which would make keyboard-centric workflows akin to writing in cursive, an overly-specialized skill that will be seen as increasingly obsolete as new forms of communication overtake them. I won't lie, that makes me sad on a level, but it would be unrealistic of me to expect others to go through the same training I did when it simply isn't as relevant to their lives.

silent_cal 3y ago

The real question is, does the quickness of using the keyboard alone make up for all the time you've spent learning emacs

iLemming 3y ago

One pretty neat Emacs trick is to bind mouse click events to toggle multiple cursors. Here's for example how to use Ctrl+Mouse_Click with evil-mc (vanilla Emacs equivalent is mc/toggle-cursor-on-click) (with-eval-after-load 'evil-mc (global-set-key (kbd "C-<down-mouse-1>") 'evil-mc-toggle-cursor-on-click)) You would just click, click, click while holding Ctrl and then you can edit a bunch of things simultaneously.

BaculumMeumEst 3y ago
do you find that you use that for cases where you wouldn’t use mc/mark-next-like-this or mc/edit-lines? i think i will try it out regardless, thanks
deafpolygon 3y ago
You can do this in VS Code, but it's Alt+Click. It's a default binding.

rgoulter 3y ago

In Emacs specifically.. A large part of the emphasis of "keep your hands on the keyboard" is aimed at beginners. Well, at least in the case of Vim bindings. Learning such keybindings has a steep cost; while learning them, it's always going to be more practical to just use a mouse. But, once you learn them, then it's often quicker. For keyboard-driven programs, I'd say a (well-configured) Emacs is the gold standard. OP makes the suggestion that using the "strokes" package functionality will have some advantages over keyboard binding. -- If it works for the user, sure. But, I'd worry about stroke recognition.. and it doesn't seem to me that memorizing a mouse stroke is going to be easier than memorising some key sequence. In Emacs, if there's some command I want to run, I'll invoke the "execute-command" with "SPC-:", find the command, then look at the keybinding next to that so I can rehearse using the keybinding.

brlewis 3y ago

Contrary to what the Dan Luu article says, I see a very specific detail from Bruce Tognazzini that takes the mystery out of the claim that $50MM in research says the mouse is faster. Once you go past the expired certificate warning you can see it too at https://www.asktog.com/TOI/toi06KeyboardVMouse1.html https://www.asktog.com/TOI/toi06KeyboardVMouse1.html It's in the context of inconsistent keybindings across different apps, and the pertinent detail is, "It takes two seconds to decide upon which special-function key to press". Contexts where you instantly know the keys to press are different from what the $50MM research studied.

mathgradthrow 3y ago

I'm suspicious of anyone who claims to be meaningfully limited by their typing speed in any task but data entry.

bee_rider 3y ago
Concern about typing speed is a devastating indictment of your programming language of choice, haha.

bee_rider 3y ago

> Even so, I use the mouse frequently because it’s often the best way to select text, images and links, do graphical work, and to interact with (both simple and complex) GUI software. “Select text” seems (IMO) like something where these microbenchmarks have an obvious flaw. If you set up an artificial test like select a continuous line of text from an arbitrarily formatted file, the mouse might be better. But we’re programmers, right? We make our code nice and tidy. Usually I want to select a whole line in a file that has line numbers. So for line 10, 10ggyy in vim. That’s pretty quick. Or I want to select the first couple columns of multiple rows. Ctrl-v, repeat j as many times as you’d like. I actually have no idea how to do that with a mouse. Anything more complicated, I begin to wonder if we want a macro, find-replace, or something else. A mouse might be better for interacting with GUIs and images but those things simply shouldn’t be done. Text is the correct way to communicate.

dingnuts 3y ago
"text is the correct way to communicate" better call your mom and tell her to replace all your baby photos with textual descriptions since those are the "correct" way to communicate and one simply should not interact with images ... if the comment I'm replying to was sarcasm, it went completely over my head. Poe's Law applies here for sure.
- bee_rider 3y ago
  It is a half-joke. In the sense that it is something I basically believe, but stated in a way that neglects nuance to the degree to which it might tip over into false-ness. Baby pictures, I don’t think they communicate much. They evoke feelings that are already in the mind of the viewer. I mean, it is basically a universal experience, to be shown pictures of other people’s kids and nod along understanding that they are justifiably excited about the objectively boring things their kids are doing, right? This is because they are excited about the ongoing journey that picture acts as a landmark for, which we aren’t a part of. So, I suppose there must an example of an image that communicates something useful out there, somewhere, but the two of us haven’t found it yet.

crabbone 3y ago

> Window selection is a natural extension of basic mouse usage. Resizing windows is a snap. I don't think I can remember the last time I needed to resize a window in Emacs. I think. Also selecting window with a mouse simply would never work for me, because I need to select them by title in most cases. This claim OP makes is just absurd. If OP was honest, then they'd wrote "in some very special and simple cases, which don't happen in practice" using mouse for selecting and resizing windows may be faster." Which doesn't have the same ring to it, obviously. > and drag and drop support I don't feel like I'm missing something if I don't have this feature. Whenever I'm faced with this feature in other programs, I'm very much annoyed I cannot accomplish the action associated with this interface in a different way (unless performing the action precisely is somehow rewarded, as in maybe it's a part of the game where you have to prove you can do things very precisely) > are very intuitive I don't care. The point of using professional tools is that you learn and practice how to use them. Intuitive is for buy-in, it's not for being good at. > The stopwatch consistently proves mousing is faster than keyboarding. Did this measurement incorporate precision? I seriously doubt that. Most importantly, mouse is only a solution for things that are or can be made visible on the screen, and it also requires paying attention to what's going on on the screen. You cannot use your mouse while at the same time looking away from the screen (which I often do), or by trying to access functionality that isn't already on the screen (which is very often what I need to do, like, accessing a particular buffer, or calling a particular command). In fact, mouse is so rarely a solution for anything I need to do during editing that even if it was faster for a very few things it can do, I still wouldn't care because I'd value uniformity of interface over negligible speedups in very few cases.

crabbone 3y ago
Also: > When working on something that involves Emacs and one of these mouse driven applications, having to move over to the keyboard for the Emacs bit is exactly the friction we’d like to avoid. This is some cooked-up case. No. This isn't needed. No, I don't feel like I need to botcher the way I use Emacs because I also like to play video games or do some digital drawing every now and then. There's absolutely no need for that. All the cases OP describes already work well without needing a mouse, or are just worthless. For example, when you want to clone a Git repository, you need to either set the current directory appropriately, or specify the directory you want to clone it to. In either case you'd be dealing with Emacs navigation in your preferred way, which would be the bulk of work necessary to accomplish the action. Then pasting something like a link to a Git repository is just one keypress (eg. Shift+Ins) and you are done. Basically, someone got excited about Strokes library, even though it doesn't do anything useful. Maybe it was fun to write, or fun to theorize about how it could be useful in some counterfactual world... but, in reality, I'd never use that and wouldn't feel like I'm missing it, even after I've learned that such a thing exists and what it does.

jrm4 3y ago

All makes sense; I went all in on the "no mouse" idea for a while and eventually came back. I suspect that, despite it all, there's something very useful about being able to see a bit of text and to physically "go to it" like one might with a pen or a highlighter, that for many has less overhead than trying to "think your way towards describing where it is?"

floren 3y ago
Sometimes you just want to point at something -- so use the pointing device!

pilgrim0 3y ago

I’ve been studying this for my research. The current conclusion so far, related to perception of flow, is that with keyboard interactions, you’re consistently and progressively closer to your goal. As for the mouse, regardless of timing to achieve the goal, there’s generally a lot of waste, that is, the energy spent does not reflect a step towards the intended goal, because you are moving into space generically and non-deterministically. Mouse interactions are prone to failure/cancellation, since the goal is achieved only at the last instant, one diversion and you are back to square one. Hence the class of actions that must be faster on the mouse are the ones where the goal is immediately and progressively achieved by spatial input, such as scrolling, drawing, etc. since energy is directly translated into effects. Mouse is obviously suited for continuous input, and keyboard for discrete inputs. For all classes of actions apt to be broken into discrete steps, keyboard control will provide consistent and reproducible results. Further, those chunks can be optimized and compressed with mnemonics, whereas mouse actions cannot be compressed. There’s no one versus the other, as both devices are complimentary. With that said, performing discrete interactions with the mouse is a poor use of the tool, regardless of anyone’s preferences. That’s a fact.

NelsonMinar 3y ago

It's 2023 and people are still arguing about whether they should use a 1960s UI technology with emacs or if the 1902 keyboard + teletype interface is enough.

globular-toast 3y ago

It's not about keyboard vs mouse. The most important thing is that you use both hands. Imagine how crap and limited you would be playing the piano with one hand. All keyboard use is assumed to be using two hands. The slow mouse usage is when you just use the mouse and leave the other hand quite literally on the table. But combined keyboard and mouse usage is by far the fastest way to do certain things. I'm not sure text editing is one of them, though.