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.)
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.
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.
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.Easy to learn, hard to master. That's what I like, because you never stop learning.
* 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.
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.
I mean in the end, who really cares though? Whatever is comfortable to you is probably the best choice.
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....
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.
Agree context switching between both too much is a pain.
`dap` was simpler for me and is easily repeatable with `.` in vim.
Either way, you're not touching the mouse.
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.
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).
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.
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.
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 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.
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.
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.
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.
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).
That’s why I use the vim plugins for vscode and jetbrains IDEs. Best of both worlds.
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.
> 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.
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)
Others' needs are different.
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.
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.
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.
(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.)
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.
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.
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.
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.
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.
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).
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 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.
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.
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.
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.