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.
For an even more configurable mouse, check out the Ploopy mouse and trackballs: 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.
Oh, that looks lovely! I'll need to check them out.
> 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.
On this topic, I bought a System76 laptop this year, and I'm in love with its keyboard-configurator. The firmware for the keyboard is also fully open source, and the GUI configurator is really excellent. It's a little limited in WHAT you can bind (without going down the rabbit hole too deep), but there are no limits at all on WHERE you can bind it, and it's beautiful. I made both left ctrl and fn work as ctrl (I could have made fn into hyper, too) and this is the first keyboard where I was able to do that (my previous laptop, Thinkpad, could only swap ctrl/fn functions).
The idea that command keys would consistently be slower sounds insane to me. When e.g. writing I regularly save my documents by keying in ctrl-s and that is demonstrably much faster than if I'd have to aim the mouse at the tiny File menu and the click and go down to "save".
Yeah, I like the conclusion from the article I linked:
> Unlike claims by either keyboard or mouse advocates, when I do experiments myself, the results are mixed. Some tasks are substantially faster if I use the keyboard and some are substantially faster if I use the mouse. Moreover, most of the results are easily predictable (when the results are similar, the prediction is that it would be hard to predict). If we look at the most widely cited, authoritative, results on the web, we find that they make very strong claims that the mouse is much faster than the keyboard but back up the claim with nothing but a single, bogus, experiment.
In other words: it depends, and common sense is still the best guide. :)
> 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.
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.
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.
Thats why I love the command palette in VS code. Keyboard accessible. Tells you what the short cut is but has everything because you probably wont remember them all
Apparently a lot more claiming evidence exists than sharing of actual evidence. One of the few things shared was a pseudoscientific explanation that stated precisely the opposite of your (and my) subjective experience:
That using the mouse is less distracting and can be better committed to muscle memory than "command keys".
I think that is patently false, and don't thing Tog should be taken as anything but a marketing hack.
Disclaimer: my knowledge of Tog is limited to what is presented in that Dan Luu article.
>The stopwatch consistently proves mousing is faster than keyboarding.
This pretty obviously wrong unless measured on very specific audience for very specific tasks. You need not to be an Emacs/Vim afficionado to know that e.g. ctrl-s, ctrl-c etc. are faster vs moving mouse to an icon, or clicking out a context menu. That's why like everyone with an experience of using a desktop of more than a year uses at least a few hotkeys
That quote seems to be from around 1989. So the studies are 35+ years old now. And they are from Apple, which had a well optimized GUI even in their early days. It's really not that hard to see Apple-researchers having better results at their preferred tasks on their own optimized interface, at a time when everything was still quite young and unoptimized.
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.
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.
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)!
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)
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
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.
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.
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 :-)
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?
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 :-)
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.
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?"
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.
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.)
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.
> 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.
> 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.
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.
> 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).
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).
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.
Yes, there is LSP support. Yes, it can be automated. Yes, you can write programs to run in acme, just like you can in emacs.
I love using acme spread across the two big monitors on my desktop machine. I can keep so much code, so many files open and visible and easily-interacted-with. However, on my laptop, I use emacs, even though emacs' frame management NEVER does what I want (go to definition? Opens in the current frame. Ugh.)
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.
> 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[...]
i know how this is going to sound, but if your only experience is those filesystems on the sysvs and bsds of the world, i am compelled to say "real filesystem APIs have never been tried". in plan 9 and its userspace tools, there is no, for instance, udev-style "doing a bunch of perilous reads and writes and symlinks followed by throwing your hands up in the air and ioctling a struct" suffering. acme's API is really nice, despite being one of the clunkier, more hastily-designed ones by plan 9 standards.
> one of the biggest productivity tips is to learn to never scroll and never move windows around, resize them etc.
acme does well here in my experience:
- the typical path:line[:column] address will take you where you expect with a right click in acme or a plumb from anywhere else (including, say, a click handler in your terminal emulator of choice)
- any time a new window pops up, there are sane predictable defaults as to where that window goes
- the simple shortcuts of left-clicking a window's handle to expand it a bit or right-clicking it to take up the entire column do 99% of what you ever want as far as "window management". these shortcuts also warp your cursor to so spamming a few left clicks is entirely thoughtless
point being, the times i find myself scrolling or dragging are rare.
> I believe Emacs has something similar to it, the thing-at-point
it's worth noting that there are two separate things at play here: plumber is a generic user-space message broker, and right-clicking is acme's built-in shortcut for accessing it. thing-at-point is ~equivalent to the latter; the former can even give give emacs new powers; example: https://github.com/alcah/sink.el/blob/master/sink.el
How would you approach following problems by representing data as filesystem?
* Represent an array with a million elements.
* Represent data-structures s.a. stack, queue, list, various balanced trees.
* Represent "structs" a.k.a. custom data-types (or even distinguish between a fixed variety of built-in data-types)? Especially how would you enable user to pass structured information to filesystem?
* Allow for custom, more meaningful errors that are sensitive to context. I.e. ENOENT is an awful error if your API is trying to represent eg. an array, then ENOENT may mean "index out of bounds" or that the whole array wasn't found. Not to mention that the error doesn't carry any information necessary to understand and correct it (i.e. if it was an out-of-bounds access, then the necessary information is how long the array is and what index the program was trying to access, if it's a whole missing array, then what path to array was requested etc.)
The above is the bread and butter of any half-decent API. I don't see how you can bend filesystem in such a way that any of these requirements could be satisfied in a way that isn't painful to deal with.
> acme does well here in my experience:
This is nothing to do with acme. It's just always a bad idea to do it. Doesn't matter if you use a text editor, a PDF viewer, a word processor -- anything to do with text, no matter what it is, learn not to scroll. The only time when scrolling is useful is if you are reading text that's long and is meant to be read in order, s.a. a novel or a play. It just so happens that this is the first and most accessible way to navigate text documents that users learn, and they tend to misapply it to problems that have better solutions.
> the typical path:line[:column] address will take you where you expect
In places where this is sometimes useful most other editors offer a way of doing this (eg. in Emacs compilation buffers you need to press RET to go to the location of the error, in VSCode terminal, it's something like Ctrl+Enter... maybe? I don't use that, but saw a tooltip hovering over such info the editor opened by a coworker). I saw this functionality in various GUI terminal emulators too.
> any time a new window pops up, there are sane predictable defaults as to where that window goes
The number of times I want a new window to pop up is very limited (eg. I do expect a new window hosting Magit's command options buffer to pop up, or a completion buffer, if similarly summoned), but I never want to create new windows or move existing windows with the contents that I'm supposed to edit. In my experience, and by looking at programmers learning how to use their editor, this is a bad habit that they need to learn to avoid.
Of course people are different, and there could be unique individuals for whom the exact opposite is true, but if I wanted to give a general advice that would apply to most, I'd insist on never touching window layout after finding the optimal layout for oneself.
> the simple shortcuts of left-clicking a window's handle to expand it
I never want to do this. And if I was working in an environment where this could accidentally happen, I'd work towards removing this functionality. For instance, in Emacs it's possible to resize the window by dragging its margins with a mouse -- and this is part of the reason I always disable trackpad, if I'm working on a laptop, so that I don't accidentally mess things by doing something like that. It never comes as a desirable functionality.
note the net argument to dial(2). the point isn't direct access (as evidenced by its encapsulation in a library, which is common in message-passing interfaces; same principle as erlang discouraging direct message sends to a gen_server pid); the point is namespacing, addressing, and protocol. "tls" is just another network you can dial on like "tcp", as are the contents of /net as, say, imported from another machine (you can imagine how trivial a vpn becomes).
"everything is a file" is miserable and, if you dig sufficiently deep, false, on unix because the unix concept of "file" is insufficiently general and weighed down with the baggage of teletypes and disks. not so with plan 9, nor with, if you prefer, a modern example: https://fuchsia.dev/fuchsia-src/concepts/process/namespaces
anyway i don't want to belabour that further as the real reason acme is relevant to this thread is the context of mousing around in a text editor:
> [...] It's just always a bad idea to do it. [...]
i mean that "acme does well" at avoiding the clumsy manual scrolling and windowing you advise against -- we're in near ideological agreement here.
> The number of times I want a new window to pop up is very limited
this is a matter of taste that traces back to the uproar against the demise of the “spatial finder” in the os 9 -> os x transition, but what i was getting at is that i do have a predictable, static layout; let me describe it: three columns i never resize in the form 80-80-remainder. terminal session and error buffer live in the right hand side, a given window dominates each of the 80-column columns, with perhaps a few titlebars of other files each. accordingly...
> For instance, in Emacs it's possible to resize the window by dragging its margins with a mouse
...refocusing within a column, whether indirectly by plumbed reference jump or directly by one click, doesn't register as window management to me. the dynamic is far more like selecting from a menu, or operating a library stack. the titlebars occupy insignificant real estate, and visually serve as an overview of the entire context i'm working with, which spares me significant mental bandwidth when either tabbing to and from another program, or getting out of my chair and back into it.
I would love it if emacs had a decent acme equivalent. You can get part way there, but there are definitely times where I’d like the flexibility of it. It’d be a lot smoother for me than setting up, say, hydra and memorising a whole list of custom keybindings.
As a concept, acme was definitely ahead of its time.
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.
> 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.
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.
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.
CAD is a stronger example (once you get to any practical complexity, naming the entities becomes intractable (and you need names to form text sentences about them), spacial selection is much more effective, even with hierarchical grouping of parts.)
Though even for text-based development, it's worth looking at Bret Victor's "inventing on principle" talks - it's more about the discrete vs continuous boundary (and that more things are honestly continuous than you might assume.)
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!
”
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.
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:
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/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?
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.
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.
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
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.
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?
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).
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.
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.
And if you are using SSH already to connect, you can use VS Code. It still gives you full capability using VS Code if that's what you're more familiar with. I'm just pointing out that it's capable. That is all.
If you're using a HPC server with no X window service, and you prefer to develop directly (no SSH in between) on baremetal like that - more power to you.
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:
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-wireles...