A mouse is an interface best suited for continuous-shaped requirement, e.g. aiming a pointer in games, drawing, and other inherently 2-dimensional arbitrary precision input modalities.

Textual interfaces (e.g. code), reading, navigating filesystems, etc. is inherently discrete (folders have files, files have words, words have letters). For discrete applications such as these, I (and many others) prefer mouseless modes of interaction. A mouse can point at many different precise points for a given character in a word, but it's still the same logical place.

(Yes, I'm aware that pixels are finite and thus the continuous analogy is "technically incorrect". Its validity stands.)

> Textual interfaces ... inherently discrete

That continues vs discrete actually makes a lot of sense. That analogy helps me put a finger on things I wasn't to articulate before.

Possibly the best explanation on keyboard-oriented workflow. Bravo!

Wow. That's a great and clear explanation. Thanks for that!

I'm somewhat skeptic regarding pro tools that take a lifetime to master (never got to like emacs for example, and I like MacOS dar more than customizing a Linux distro) but there are some mouseless skills that are such a game changer for me I almost can't use a pc without them, everything else becomes too frustrating. Vimium to browse the web is a Godsend for example.

No need to learn for weeks, it's:

-j/k for scrolling

- J/K move around tabs

- f to click a link

- gg/G to go to the top/bottom of the page

- o to enter new url

Not exactly the most intuitive keywords if you haven't used vim, but you try that a couple hours and then using a mouse feels like clicking edit -> copy instead of doing ctrl-C.

I took a look at all of the shortcuts that Vimium offers, and beside the f/F to open the link, other shortcuts are already available natively in Chrome, like:

* arrow keys/PgUp/PgDn for scrolling

* Ctrl-PgUp/PgDn for switching tabs

* Home/End for top/bottom of page

* Ctrl-U for source

* Ctrl-L for switching to the omnibox

* etc

I guess some people might wince at the fact that they have to touch the arrow keys or Home/End/PgUp/PgDn, but my keyboard has those keys and I'm used to it.

Besides the fact that you leave the home row, I'm not sure why but scrolling is quite significantly better when using vimium, at least on macOS.

Using the arrow keys makes the page scroll jerkily, in a way that complicates reading while you move. Using j/k (or u/d for fast scrolling) produces a smooth result similar to scrolling with the touchpad or a phone/tablet scroll.

There's also H for opening a previous history entry or switching to a different tab you have open. This is a big one for me (along with the Auto-Discard extension) since it lets me keep a very large number of tabs open and not have to iterate through every open tab when I want to find something I opened previously again.

I use a 60% keyboard, so the arrow keys map to "fn + WASD", which gives me the 'benefit' of not having to move my hand to a dedicated mouse cluster while still being an easy to use key-combination as WASD is natural to gamers.

I mean in the end, who really cares though? Whatever is comfortable to you is probably the best choice.

You can now add a trigger to focus things instead of click them too, which helps with some hover based menus.

I'm a vimium user and I wasn't aware of this, how useful! I checked the docs and I can't find it, do you know what it's called or how to do it please?

If you go to Vimium options and enter this line into the custom key mappings it should work:

    map c LinkHints.activateMode action=hover

You can change c to whatever key you want to trigger it. It works perhaps less often than I was hoping for, a lot of menus still won't work, presumably because they use JS or something else to trigger the menu.

These tools take a lifetime to master, that's true; but I could code in Neovim in two weeks. I think if you decide seriously to learn it, you can be effective with it pretty fast.

Easy to learn, hard to master. That's what I like, because you never stop learning.

The thing about a mouse interface is that it's a lowest-common-denominator approach for a lot of things that works pretty ok. Certainly better for that than the text-only interfaces it's largely replaces. This is also why the web is so married to it, 'cause you can navigate around a bunch of semi-consistent information.

The average confused user will probably do better randomly mousing around than trying to juggle keys, or even worse "visually" navigate using arrow keys or something.

But if the interface is powerful and the user is skilled (both significant "ifs") then important operation can be done before your hand would reach the mouse, let alone do anything with it.

I suspect the most efficient is a mix of both, mice are pretty good at selecting from a long list of options, for example.

A lot of IDEs these days contain pretty underpowered editors and slow you down by relying on the mouse too much. If that's all you've tried, you may not have any idea why keyboard interfaces can be a lot more efficient for some tasks....

I agree with most of what you're saying. Now, about the skills of the users, I think people are smart and can learn more easily than we think, if and only if they're taught right.

It's what I tried to do. I don't know if I succeeded, but so far I had only positive return, so it's encouraging :)

About the mix of both: I agree if I'm a long period on my keyboard or on my mouse, but not interleaving the use of both.

The point about skill is that an unskilled/inexperienced user is typically going to have more trouble navigating a keyboard based interface than a mouse based one - nothing about how easy or hard it is to gain that skill.

Agree context switching between both too much is a pain.

Once upon a time, I was a Vim user. I learned many of the commands, such that a typical day involved swatting at the keyboard like it's a drum set. But I later realized that half of the satisfaction I felt I got out of Vim was just the feeling that I could, more than that it was actually that fast. Sure, some things like macros can be much faster in a given situation, but the amount of savings you get from typing Shift-V % instead of picking up the mouse and dragging over a paragraph is not really that high compared to the amount of time you spend writing and thinking about code.

The difference for me was realizing that Shift-V % will typically highlight precisely what I want - though that's a bad example, visual mode is rare for me. More frequently it's something like `dap`, which works with a level of precision across lines that aren't necessarily all on screen. If I click and drag, I'm liable to select one extra or one less line, e.g.

Is this better than using the keyboard with arrow keys and ctrl/alt/shift?

I could never remember what the ctrl/alt/shift modifiers do and never managed to get fluent with them - they also require repeating movement many times by holding/tapping the arrow keys until you get to where you want to go, so it feels imprecise to me. I've seen plenty of people who are much better with the arrow keys than I am so I know it's possible to do very well with it though.

`dap` was simpler for me and is easily repeatable with `.` in vim.

Either way, you're not touching the mouse.

Well, vi already allows considerably more than 4×4 different references to text objects relative to the cursor, and vim adds some others on top of those.

I guess if you include chords of modifier keys, you could have 2⁴×4 possibilities, which would be extremely competitive with vim in this regard, although I haven't encountered an editing environment that did that. (That's not to say that it couldn't exist.)

I consider myself a proficient but unsophisticated vi user, and I seem to have at least 19 cursor movements that can be combined with selection or deletion in my muscle memory, in the sense that I would regularly use them without being consciously aware of how I chose one movement command rather than another. And that's not counting the ability to prefix them with repetition counts, which is usually a more conscious activity for me. I know that vim provides another dozen or more that I've never learned well, but it seems like other people have.

It does take time to internalize these, which is one reason we see so many people making "learn vim" games and tutorials. And I could imagine that they might not be the exact selection of movements that someone would find optimal, let alone easy to remember or articulate.

For those of us who can type very quickly, every movement of the hand away from the keyboard (to the mouse) and back has a high cost in terms of lost typing opportunity.

If speed and subconscious operation are the goal, then it's best to stick to as much keyboard only as possible, or alternately to learn to maximize the one hand keyboard + mouse approach (which can actually be very fast once you know your tools).

For most of us mortals, typing is not the bottleneck when we are writing code, an article or whatever.

In any case, keyboard-only interfaces make the assumption that you know all of the shortcuts for each program you use. And boy they are inconsistent. They also offer zero discoverability for someone that did not read the manual (see the vim jokes). I like software that offers both good pointer UI + robust keyboard shortcuts for those who have learned the ins and outs and need to go faster.

We're all mortals :).

Like other endeavors of growth, a good approach is to regularly make a small effort to learn a little more about something (like your tools, which includes keyboard shortcuts).

As one simple example, if you have a URL somewhere and you want to quickly open it in a new window, you just use the keyboard shortcuts to copy (which hopefully everyone knows), switch to browser (alt-tab or cmd-tab or even [cmd-space fire return]), ctrl-t or cmd-t to open a new tab, paste, return). This sequence becomes so hard-wired that you can go from seeing a URL to reading it in a new tab in a couple of seconds. And since it is hard-wired, your train of thought is not interrupted with common small thoughts like, "hmm where is my mouse pointer? wiggle mouse - ahh there"

But like I also suggested, with left hand on the keyboard and right hand on the mouse, and knowing a few very common shortcuts, you can be very fast at getting things done.

In both cases, knowing keyboard shortcuts is... key.

Lastly, there are some awesome tools like Keyboard Maestro or possibly Hammerspoon (I use the former, but have heard the latter is decent). With a bit of effort, you can make some really useful macros and do a lot. Heck, even just using Automator can do wonders. For example, it's pretty easy to make a file right click action that will resize and export an image into one suitable for web publishing.

The summary of all this really is that learning your tools makes you much more effective and performant. Seems obvious, but it's easy to forget.

While all true IME the ever growing stack of libraries, frameworks, languages, and infra tools one must learn leaves little breathing room for modest gains in text wrangling.

Most of my time isn't spent slicing and dicing snippets or juggling windows. Rather it's thinking, planning, a bit of experimentation, reading, repeat.

And powerful, built-in auto complete with visual IDEs like IntelliJ or PyCharm make them hard to give up.

I thought the same before trying to use my actual dev environment, but, at least for me, it felt more enjoyable to stop using the mouse when I was coding. I think the best is just to try both approach and see by yourself.

Even still, cmd-opt-b when your caret is on a name jumps you to the code where that thing is implemented. A few shortcuts like that make navigating so effortless that you are free to focus on the code and libraries.

Sorry if I was unclear. That's one of my favorite shortcuts actually. And I write my own Bash aliases and scripts to reduce terminal fatigue.

I just don't devote much time to mastering text editors. In fact I've had to change editors so often that mastery may have been unrealistic anyway.

The problem is not necessarily to be fast for me (I know people who are very fast with the combo mouse / keyboard) but more if you like it. If you don't enjoy working with your tools, you'll have a lot of friction to do your work.

I'm not sure everybody would like a development environment as I describe it, that's why I invite people to try Vim for example for a couple of week (I've some free articles on my blog about that) or i3, and see what they think about it. Exploring new possibilities is never bad.

About learning the tools: I agree, but you can learn much more from some tools than others. I think of Vim as easy to learn, hard to master because there is so many stuff you can do with it. But I used Intellij IDEs as well for a long time, and I don't think it's hard to master, because there's not so much you can master, except maybe the keyboard shortcuts.

With all due respect, as a self-identified mortal, typing often IS the bottleneck when I'm coding. This is why I often write pseudocode on paper or a whiteboard, before typing things out. Not sustained typing, but in bursts. Particularly when there's some complicated logic. When I reach that moment when I finally have a breakthrough and clearly understand what I need to do.. that moment is fleeting, and it's vitally important that I get it written down before I forget. Like waking up from a dream.

> keyboard-only interfaces make the assumption that you know all of the shortcuts for each program you use

That's why you carefully choose programs that are highly configurable so that you can integrate them seamlessly into your particular workflow.

The reason I use Emacs is not because it's a great editor. It's slow, often frustrating and since adding LSP support it crashes frequently. The reason I stick to it is because it gives me endless customization so that I can decide how I want it to work, instead of the author or some company deciding that for me. Learning to use it is therefore an investment in future time saving since I won't have to worry about it drastically changing or moving to another system if the company that supports it decides to change direction.

I don't think vim could speedup your typing speed (unless you are using macro/`.`). I think the benefit of vim is mostly about code navigation, and this is the bottleneck (at least for me) when writing code: jumping around definitions, from and to different region, without having to reach the mouse and click on different buttons.

Good pointer UI + robust keyboard shortcut is quite good, but sadly most of the GUI applications do not allow you to use a consistent set of keys in different controls, but with vim you can. (use shortcut to open up some form and suddenly the shortcut changes, and rarely you can configure those shortcuts). And having a normal mode really appeals to me, as I don't have to reach ctrl/alt that often with normal mode.

I totally agree with that. To me, flexibility is the way.

Something I hate for some GUIs: they sometimes change their interfaces without any reason. I think about the whole Confluence thingies (worst interfaces ever IMHO), or even intellij IDEs. When I was working with them, I saw the preference menu changing at least 4 or 5 times. Perfect to confuse me. That's why I accepted to try the tools my colleagues where using, the ones I still use today.

On top these tools allow us to have a configuration in plain text, which is so easy to manage because we have so many mature tools to deal with plain text (git is a great example of that).

Home row cursor movement is one of my favorite things about vim. Same with w, e, b, ^, $, and the c or d commands used with them. I think just knowing a small few navigation keys and a small few modification keys, your capabilities are multiplied.

That’s why I use the vim plugins for vscode and jetbrains IDEs. Best of both worlds.

It's not because you do jokes about a tool that this tool is not good.

> In any case, keyboard-only interfaces make the assumption that you know all of the shortcuts for each program you use

When I use Gimp, I need to know where are the different options I want to use. It took me time to learn where I can find the best tools for my own needs. It's the case for any interface, GUI or CLI.

But where some CLIs really shine: you can customize everything to create your own little world, to bring a consistency between all your tools. That's the real power: flexibility.

It has its drawbacks too, but I the benefits outweigh them big time.

The editor I use says CTRL-K H for help in the title/status bar, and if you push ctrl-k then h, it has a handy dandy help screen. It's not as nice as F1 for help that used to be universal in Windows, but the F keys in terminals never got traction that I saw (quite possibly because of lack of standard availability in the 80s; everyone had a CTRL key, so just use that).

UI gestures are pretty undiscoverable without documentation too; but there's no manuals anymore. Even the books like XYZ: The Missing Manual are few and far between. At least editors from the 80s and 90s have documentation, even if nobody wants to read it.

/rant (not directed at you)

So you are the single user left with jstar :D

At my last job, there was a user group for joe. I joined it, and it became a users group. So there's at least two of us. I didn't stay in touch with that other user when I left that job though (although, I did make sure to send a farewell)

> They also offer zero discoverability for someone that did not read the manual (see the vim jokes).

I don't see why I would use a specialized tool for hours a day without reading the manual.

> good pointer UI + robust keyboard shortcuts

vim jokes aside, you can use a mouse with vim, terminal, tmux, etc just fine. I sometimes do, but most of the time I find the keyboard simpler.

As a mere mortal with limited Working Memory, the bottleneck is getting sketch-thoughts out of my head where I can see them and edit them.

Others' needs are different.

> I never got the hate of mouse in the dev community. Isn’t most of work browsing code and Googling things?

So, for example, I use a plugin called Tridactyl in Firefox. It allows me to select any link, any button, or enter any text box in just a few keystrokes. I hit one key to tell it "I want to click something", essentially, at which point it highlights the links & assigns them letters; then I type the letters corresponding to my choice. It's competitive with the mouse.

Firefox isn't too bad without extensions, either, since it has the ' key. (Find, but restricted to links. So, ' + type the link text until match + Enter.)

My work keyboard also has keycombos that I can turn a few of the keys into a crude mouse, but it is so slow that it's usually not worth it.

You should try qutebrowser :)

Vimium on Chrome

> Isn’t most of work browsing code and Googling things?

Browsing code is easy to do with a keyboard - not sure I see how a mouse would improve things.

Browsing web: Firefox has since forever let you go to and open a link by typing a few characters in the link. I'll grant I don't always do it this way, but it is quite fast - unless the link is an image or something.

Finally, if you're one of those people who've had ergonomic pains, then avoiding the mouse can really help (depending on what the pain is).

But yeah, obsessing over not using a mouse is taking it a bit far.

I see a problem here: I'm not obsessing not using the mouse. There are some very loud people out there who are dogmatic anti-mouse. As a result, everybody speaking about a keyboard-oriented system is considered as a dogmatic.

It's not my case. I just think that when you deal a lot with text, like a developer, letting your hands on the keyboard is way nicer, instead of switching all the time between keyboard / mouse.

But I love to use the mouse when I'm on Gimp, or when I do some music, or when I post process some photos. You should use the best tool depending on the task.

Firefox keyword searches are the way to go - you can setup URLs with arbitrary %s variables and go directly to the results page for a given tool. I have one or two char shortcuts for my most commonly used tools setup and my productivity exploded. With bookmarklets you can embed JavaScript and do things like implement parameters or loop through lists of search terms with each term opening a new tab. Seriously one of the most underrated tools available for anyone that has to use web tools all day.

Navigating code using Vim keyboard commands (in Vim itself or another editor with a Vim plugin, like VS Code) is actually efficient and comfy once you become fluent with it. I also use a Vim Firefox extension to minimize my mouse use browsing the internet.

(That said, creating a fully mouseless Arch Linux desktop environment is way more hardcore than anything I want to do, especially considering the less-than-stellar stability of desktop Linux.)

I'm using Arch for 6 years now, I never saw it crashing. It's the most stable system I've ever seen.

To me, "arch is unstable" is more an urban legend than anything else; the best is to try. And I can compare it to everything else I used for years: Win98 (oh my), winME (such a joke), win XP (way better), win 7 (really stable), Ubuntu (I had the impress to come back to win98 each time I was doing an upgrade), Debian (quite good), macOS (quite good because they don't allow you to do anything to crash the system, not nice when you have a problem). And so on.

And it's really not that difficult to install. I've one more chapter after the sample of the book I provide, and then it's done.

> I also use a Vim Firefox extension to minimize my mouse use browsing the internet.

Which one? Vimium-FF? How well does it compare to Vimium in Chromium?

I've been wanting to switch from Chromium to Firefox but can't live without Vimium. If it works well, I'll make the switch.

I've only ever used Vimium-FF, so I'm not sure how it compares to the Chromium version, but it worked well enough. Now I use Tridactyl. Check it out. It takes the concept a lot further than Vimium.

I just checked the GitHub page for Tridactyl, it seems to have so many features. Do you have any frequently used feature that only Tridactyl provides but not Vimium-FF?

There was a HN post[0] recently about that, you can find more insights reading the comments. I went from vim-vixen to vimium then to tridactyl. As for features that only Tridactyl provides (things may have change in the meantime) I must say that I absolutely love their hinting mode. It's totally different from anything I have used (even qutebrowser's which is completely keyboard focused [1]). It also provides a desktop executable that allows you to edit everything in Vim. That said, I've been using it for 6 months and I know I only scratched the surface.

0: https://news.ycombinator.com/item?id=24615787

1: https://news.ycombinator.com/item?id=24636160

sure. i think the big ones are all kind of related: - a proper commandline, not just "open url / search" field - everything's an excmd. you can compose them and write your own. you can bind them to keys or use them adhoc. - you can define excmds that execute javascript snippets - ~/.config/tridactylrc

(oops, those are supposed to be bullet points. seems it's too late to edit now.)

You should try to use qutebrowser. I quickly speak about mouseless ways to browse the internet in the book, I think qutebrowser is the best solution so far.

Generally shortcuts are far more efficient - navigating via vim movements are incredibly fast for proficient users.

Same holds true if you use excel, shortcut gurus generally far faster to accomplish the same thing.

Back when I used to play World of Warcraft, you could tell the clickers snd how bad they were comparatively against dudes who had hundreds of bindings.

That's something which is quite a paradox to me: many people will love using a GUI for coding, and at the same time they will use shortcuts 99% of the time. I don't get that.

You can make keyboard more efficient than mouse for everything, even browsing code and googling. Tiling window manager + vim or emacs editor + vim or similar keybinds for browser.

It takes some upfront work to get those keybinds into muscle memory, but once you're over that hump a mouse feels cumbersome and clumsy by comparison.

For me personally it's just slower and more cumbersome. I don't even buy into the whole ecosystem, just i3 and vimium for chrome, and I feel way more concise. For me it's about doing precisely want I wanted quickly and not wasting time humouring the GUI.

Someone brought up the difference between modern UIs on here, mentioning that you are often clicking, then waiting, then clicking, then waiting. With a CLI tool you can do all your actions up front and in sequence and then let it run. You don't have to be present for the waiting.

I don't hate the mouse, but I think staying on the keyboard when you work with text (like code) is way more comfy. The problem is not the mouse, it's always switching your hand between keyboard and mouse.

Additionally, the system I describe in the book is centered around the shell, and it has so many good and mature tools for you to deal efficiently with text.

I love the mouse for graphic design, music composition, photography (post processing).

> Isn’t most of work browsing code and Googling things?

Browsing code is mostly done in an editor with the keyboard, for me. And Googling things isn't exactly something I spend hours a day doing.

Additionally, I make more mistakes clicking slightly outside what I'm trying to click on than I do using keyboard shortcuts which work without precise fine motor control.

Mouse is slower than the keyboard. It requires focus and precision.

Mouse is more finicky in many environments which are not a surface which is not a stable, flat, non-reflective, non-moving, non-vibrating desk.

But most importantly, moving the arm from mouse to keyboard, back and forth, over and over again, creates much strain, which translates to pain and long time-outs.

And IMs, meetings, and just thinking about code. I think it's important to be able to touch type quickly and efficiently use autocomplete because those are directly in the way of transforming your thought into code. But in the times I'm bouncing around with a mouse, it's already coding downtime.

I didn't think about that, but now you speak about it I think it's true. Thanks for that, that's interesting.

If you're gluing existing APIs together it may be true, I'm writing stuff from scratch for the most part and don't open a browser.

That said I control my browser with the keyboard and navigate my code from the command line. I suspect have similar workflow / opinions as op.

It's not mouse hate, but an alternative way to use a computer.

Exactly. As I was saying in another comment, I have the impress that some people are very loud and dogmatic about these ideas: "you should NEVER use the mouse or I'll burn you as a witch on the village square!".

But I don't think the majority of the community around CLIs and keyboard-driven workflow are like that. It's just we like it, and we see benefits in this approach.

if you want to sculpt, better get to know the chisel.

The keyboard is inevitable for writing (if that's what we talk about), so if any, the mouse may be dispensable. And reducing moving parts can help to improve focus.

P.S.: when approaching the cliff, 'retrograde' may be the thing.