Show HN: I wrote an entire book to build a mouseless dev environment

Hah! If I kept count of every time I heard that about Vim, and then went ahead and read the article and learned yet another new thing about Vim, well, I'd be getting pretty good at Vim...

Don't sell yourself short. Even just seeing how others use the same software you use can be eye opening. I'm going through the linked PDF now.

One question: what did you use to make the book itself? I noticed the links in the chapter don't work, at least in Firefox's PDF reader, so if that is unexpected it might be a point to improve.

This makes one feel like a broken record, but this compels me to mention that there are major differences between 'gratis' and 'libre'.[0]

Open-source/free and for-profit are not at odds with each other. They describe different ideas.

[0]: https://en.wikipedia.org/wiki/Gratis_versus_libre

- read code - check docs - write code - test and look at logs

I use the keyboard for 80% of my work and regularly people (including devs) are in awe of the speed of my movements. I would even go so far and say that it improves Flow (psychology) by reducing mental overhead (muscle memory).

Best wishes! :)

I just wanted to mention that a few years ago I swapped over to dwm from i3. If you haven't tried dwm before (it seems relatively little-known these days), then it might be worth spending an afternoon trying it out to see whether it suits your workflow as well as it does mine!

It's a lot more opinionated than i3, but if its opinions happen to match yours then it requires even fewer keypresses to zip windows around!

1. You write something broad as you say. You present many options to the reader. The book is not practical anymore, because you don't speak about something in particular but some general ideas. As a result, the readers can't really practice with a concrete project, and they might end up lost in an ocean of links. If I wanted to do that, I would have created another "Awesome list of Linux tools" on GitHub.

2. You write something more focused, as I did: the readers can practice, you can describe and explain everything they're doing because the focus is more narrow. You eliminate a whole class of problems as well, because you know exactly the tools they're installing and using. As a result, you enable them to understand what's happening.

I went for the second solution, because I think we lack books which are really practical. I wanted the readers to be actively engaged into a project, learn by practicing, and be able to swap every tool they want afterward. Because they'll have a deeper understanding of Linux, a modal editor, a tiling window manager, and so on.

It's not because I use these tools that I want to impose them to the world. I choose these tools for the book because they allow the reader to understand what's happening under the hood. Even if I was using another wm or another distro, I still would go with these tools, because it allows me to teach what I want to teach. Because they're not too difficult for beginners if you explain them right. I think people are smart, and I think they can learn way easier than most people think.

To me, Ubuntu is highly opinionated. Who cares? It's not about me, it's about what the readers can learn from the experience. I'm not convinced you learn a lot by installing Ubuntu, or that you understand the benefits to work with a tiling manager, or you understand the important place of the shell in the Linux ecosystem.

Thanks for the good luck :)

The target audience obviously won't be a someone who already loves to tinker with a lot of different setups.

A book like this will be much better if it introduces an opinionated setup to follow.

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.)

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.

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....

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).

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.

(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.)

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.

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.

1. The reader would bump into many more problems because the book is less focused. It's about installing a whole system, so many things can go wrong already, and I wanted to reduce the friction by being precise. To be precise, I needed to know what tools the reader would install.

2. I use these tools because I know they can teach a lot of fundamentals. This means that, when you're done with the book, you should hopefully have enough knowledge to swap anything you want, even the Linux distro.

I think you're on something about the sample. You can look at my blog though, there are many free articles (look at the "mouseless" tag) which are more general and capture maybe better the essence of the book.

There is no paperback copy available, because there are many commands and pieces of configuration in there, and I thought it would be easier for everybody to be able to copy and paste.

That said, if there is a demand, I would be happy to look at that.

Last thing: I explain everything in the book, so you don't have to stick with this system at the end, you should be able to build your own depending on your needs. You can swap any tool you want (even the Linux distro if you want), hopefully you should have enough knowledge to do that easily.

If you are constrained by the speed of your typing while "programming", you are not really a programmer, you are just a secretary with a typewriter.

Sure, actual writing is 5%, but the 95% remaining isn't just thinking, so it also benefits from muscle-memory switching to docs/test/code panes.

My dev env is mouseless (I use Vim and AwesomeWM instead, though) except for everything corporate (Gitlab, notably) and it always feels like a drag and slow AF. Only now I added vim-mr-interface and even with its shortcomings it's like night and day.

I used to think this was a property of my aphantasia. However, in recent years, I've heard a lot of people claim that writing is thinking. In fact, most writing out there is an artifact of thought, and not designed to be read by others. Few people recognize that distinction, and that's why good writing is so rare.

However what these kind of books/posts fail to sell is as much as software development is about building code to automate things, at some point in time one wonders if software development itself can be automated to a very large extent. The answer is writing code is a way of hand writing structured text. Therefore code should be generated like the very way we generate XMLs or JSONs. Compilers are a tool does that for a fixed set of syntactical things.

Now is it possible to have some kind of means, methods and techniques for general code editing/generation. Note this has nothing writing code faster. But this has to do with human labor required in achieving a thing. Eg. How many steps does it take to delete 10 lines of code with mouse vs typing 10dd in vim? Scale this problem for 500 lines. And see how deleting with a mouse requires one to execute as series of steps scrolling, selecting, hitting delete vs 100dd. Now how many takes does it take to delete 1000 lines lines? Say selecting 100 lines at a time, scrolling, deleting. Basically 30 steps vs 1 step(1000dd) in vim. Notice how adding more lines to deleting in a notepad'ish editors increases complexity of deletion O(n) vs 0(1) in vim(ndd)

See where this is going?

Now take this one more example. Say you have three tabs. You have to copy 3 lines from the first tab, delete the current line in the next 2 tabs, and paste the copied lines from the first tab. Say you have to do this for 1000 times. Notice how you have to do 1 copy operation in first, shift across 3 tabs one at a time, while deleting lines and pasting them. If you had to do this, just imagine mental and physical labor into this. Now let me introduce you to this cool little thing in vim/emacs called a keyboard macro. You can tell the editor record these key strokes and play it for me n times. Congratulations now you just went K x O(n) to O(1).

Let me make this even more attractive for you.

Let's say for every line of editing in first tab, you had to make 3 edits in second tab, and for every 1 edit in the second, you had to make 10 in the third. Human's were not born for to do this kind of sisyphean tasks. We intelligent species were born to arrive at O(1) from every O(n^k) tasks life has to offer us.

This is just one part. But there are many other examples like this. For example in Apache Pig, its common to write projections like $0 AS apple, $1 AS banana, $2 AS cherry... see no human should hand write code like this. It's not about speed. It's about wasted human labor. If there's structure to something it should generated.

If there's structure to not just code but anything we do it must be automated.

What needs to be taught is to see wasted effort and show us how to save it. Mouse or no Mouse, that's irrelevant.

Every human should refuse to do work, that can be done with a computer.

And a quote from there: "The basic summary is cursoring around required a higher level of mental planning to organize the interaction, which apparently obscures the perception of the passage of time--think of being deeply engaged in something and being surprised when you look at a clock-- whereas the use of the mouse was done at a lower, mechanical level that left the mind free for higher things, such as complaining about the mouse."

Don’t be surprised; plan9’s acme is not a popular application and its mouse orientation is too radical for high flying reviewers to grasp the merits of its original workings.

That said, I don’t want to use a mouseless environment, I just want the mouse to be useful and efficient when I use it.

I think it's just that: exploring new possibilities. I'm happy I tried mouse-driven and keyboard-driven workflow, because I could choose what I like the most.

I didn't know about Acme. Thanks for that!

A wacom screen is intuitive, but surprisingly hard to use.

Then there are all of the rsi implications of a mouse. I use a roller mouse that I love, but older members of my family just can't figure that out.

I speak quickly about mouseless ways of browsing in the book, and to me the best solution would be qutebrowser for browsing the Internet IMHO. You should check it out.

I'm using these tools to stop switching between my mouse and my keyboard all the time. It might not bothering you, and it wasn't bothering me either before I tried to spend most of my time on the keyboard.

After that, like many things in development, it's a question of preferences; but you can try and see for yourself. You don't have to buy the book for that: I've many articles about mouseless tools on my blog for free for example, and there are even more on Internet :)

Touch typing is not only about typing faster. It gives you this other ability of "running your control panel" out of the home keys only (four fings on each hand resting on a,s,d,f and j,k,l,;). When you have to lift one of the hands off the home keys and move it to the mouse to do anything, and I mean anything, it's super annoying and frustrating.

Those who never learned to touch type are not likely to grok the appeal of mouseless work.

It's my first time using i3 or any tiling WM for that matter. Took about a day to get used to the basics (sane defaults), and that's mostly all I've needed so far.

My one attempt to use the dedicated installer didn't work properly so instead I installed Ubuntu and then Regolith from PPA.

I've been using Idea essentially without a mouse for a few years now. It takes a little bit of time to get used to all the shortcuts, but it definitely pays of in the long run.

0: https://github.com/alacritty/alacritty/blob/master/docs/feat...

I tried emacs (I like to try many stuff :D) but it felt a bit too much "program which does everything". I'm a big fan of small programs which can complete each other. You know, the Unix philosophy: "Make each program do one thing well".

I'm not a big fan of the keystrokes either, but maybe it's because I'm more used to Vim. Maybe I should try more seriously one day.

I know because I had been on some of those unfortunate teams that transitioned to GUI that required to use the mouse and the teller's productivity decreased terribly - something that took 30 seconds ended up taking almost 4 minutes, and seeing this, the banks refused to transition to the "new and advanced" versions, until the old charmode UI was slapped on it again.

I think it depends how you try it. You need to go step by step, not swapping your whole system from one day to another. That's why trying these tools on a virtual machine for example can be nice. You don't have to use them, but you can come back to them when you feel like to. Or use them only for modifying config files and not your whole codebase, for example.

In any way, I'm sure you'll learn some stuff about Linux-based systems. It's always useful I think.

For problems I have in programming languages, either way I look at the implementation of some unknown stuff (class, function, and so on), or I go on the official doc.

Other than that, there are many solutions for browsing without the mouse (but they're not working for every website). You should look at qutebrowser, or some browser extension like Vimium or Pterodactyl. I speak about it quickly in the book.

[1] https://chrome.google.com/webstore/detail/vimium/dbepggeogba...

Welcome, brother (or sister). We'll sing while burning some mice and love each others using a limited amount of keystrokes.

> you are not bored typing for the milionth time a for loop?

I don't really follow you. Do you ever use a bicycle? You are not bored pushing for the millionth time the left pedal?