In the beginning was the keyboard
I recently read an essay by Niel Stephenson that felt at times like it had been written for me to read right now. It was like some of the paragraphs were exactly what I wanted to read when I wanted to read them. The essay was about some early history of programming, from the mainframes to the beginning of the 2000's. But alongside that was a stark and very partisan view of what was the right way to do things with computer machines. In particular, he was a fervent critic of GUIs as the opposition to the simple yet more powerful and efficient terminals. And without a doubt I couldn't agree more. If you ask a non-programmer if they would prefer to do the same task in a GUI or in a terminal there is only one possible answer - the GUI. I was in that camp of people not less than two years ago. The reason is very simple and I will try to explain with a metaphore: say you need to make an omelette but you don't know how to sauté (the flipping), then you likely will do that step manually and move on with life; the risk and learning curve with sauteing is not worth the few seconds gain for today's omelette. But more importantly, if you don't regularly cook with somebody that does know how to sauté, you will probably be convinced that sauteing is in fact less efficient than manual flipping.
This is obviously false like anybody who has learned how to sauté before can tell you. But it also has another layer that is easier to miss. And that is that the outcome will look better because learning to sauteing is also partially about learning how to cook. It is rarely the case that the act of learning to sauteing comes in a vacuum, it usually enriches your cooking experience in other ways that are hard to anticipate beforehand.
After this convoluted metaphore it should be clear that the comparision is between terminal (sauteing) and GUIs (manual flipping). When you normalize something (like using a GUI for everything) it is a lot easier to remain complacent about it, no matter how bad it is, because the alternative not only becomes hard to reach but may even be unkown.
Having lived in the other side of the camp for a long time (i.e. using GUIs) I am well too aware of how easy it is to feel at ease with GUIs and not even understand all its limitations. But once you have reached the other camp (i.e. terminals) it is almost impossible to come back. It's a strange feeling the sensation of using TUIs, CLIs, or simply the terminal in a keyboard-driven manner. I never felt it was about efficiency, or productivity - although that certainly can come along with it. It always felt about piece of mind. The feeling that the limitations were clear - whatever is on the manual - the speed was predictable - not about how bloated a certain GUI was - and overall a sense that everything was in its place. Now one of the key appreciation I had about the command line and the terminal was that everything could be done from the keyboard. I don't know if it was lazyness or what else but the sense of not having to reach for my mouse gave small bursts of joy. I felt that when I was not using my mouse I was losing less focus, keeping more flow and not constantly having to worry about where the developer had placed a given feature in the UI (which would usually be in the last place you would expect it to be).
So over two years ago I embarked on a quest that was at first unconscious and only with time passing became more purposeful: trying to remove the mouse from my day-to-day activity.
My initial failed searches
This search started around four years ago when I was navigating still in the waters of Windows machines (I still am partially today as well I am afraid but by no choice of my own).
While in the beginning the gains were incredible, soon things started to slow down. At the time I was using VS Code and I soon discovered vim keybindings within VS Code. I used it for a bit and then gave up - it all seemed cool but the steep initial learning curve had proved enough to tease me out. But luckily enough the quest continued outside of IDEs and I soon landed on vimium, a Chrome extension that allows you to control the browser mostly with no keyboard need. It has a series of vim-like keybindings that allow you to do 90% of browsing without ever touching the mouse. There are some things that felt still very clunky like dealing with cookies and pop-ups but that was a huge step-up from my prior mouse-driven browsing experience.
At the same time I started experimenting with tools that would allow me to orchestrate the movement across apps better. From very simple keyboard shortcuts like Alt+Tab to more complex pieces like Flowlauncher that allowed me to open apps and files a lot more efficiently (especially more efficiently than using the Windows button that usually lands you on an Edge web search rather than opening the app of choice). Likewise I started to appreciate other cool ways to move windows around space with shortcuts like Alt+space and the like.
While the vim initial start had been a failure (we will come back to this) the following few months had been a resounding success. But as with many things there comes a point of a plateau. With many plateaus, it is just a matter to keep going before you reach the better part of the curve, but in this case I was after a much more grim discovery.
Despite continued efforts I did not see much improvement and there were still so many things that kept bugging me. First off, I realized how hard it was to customize things (from re-mapping shortcuts to adapting shortcuts for specific actions to accepting the UI of certain actions like how Alt+Tab switches between windows). Second, I was puzzled at how slow things were. This is when I realized that the plateau was not about the tools I still needed to learn (although this was certainly still part of it) but it was about software. Windows was the problem and there was no way to get around that.
In the meantime, for completely separate reasons I had decided to install GNU/Linux on a new machine I had bought (what I am writing in right now). This is not the place to say how happy I have been to make the switch from Windows to GNU/Linux - that's for my previous blog post to do - but I certainly would not be writing this one post if that had not been the case. Linux opened a new way to finally feel like I could own my actions around the device, and I can happily say that although I do still have a mouse I rarely use it less than 10 times per day.
Unplug the mouse
So here I am finally being able to tell the true story of how moving to a keyboard-only life has fared me. Since I moved to GNU/Linux things have been great - and I wish I could take back the years I spent struggling with Windows making less progress in ten times the time to devise a keyboard-driven workflow. Now just for fun and recording purposes I will briefly discuss my GNU/Linux current set-up (which is in no way optimal or a way to encourage it but simply what has made me very satisfied to use over the last few months since my moving to GNU/Linux).
Step 0: Unplug the mouse. I have never actually done this because there will always come a few cases where it's just better to use the mouse, but I always played with this idea.
Step 1: Distribution + window manager. When I got started I had not a lot of knowledge about Linux so I installed what seemed like a simple distribution (Ubuntu) and a straighforward windows manager (i3). Both of these were great out-of-the-box but I enjoyed making some customization to i3 - to make the shortcuts easier and add a few things not provided at the start. And I should note that this was part of the aha difference with my previous attempts where if something was not available out-of-the-box it was likely not available at all in a Windows machine.
Part of the beauty of using the keyboard (assuming you are a touchtyper) is that you don't have to move your hands as much around. In particular my favorite keyboard shortcuts are those where I can type the leading key with my left hand (e.g. Ctrl, Win, Alt) and a key that is in the home row of the right hand (e.g. h, j, k, y, u, etc.). As a result, some of the adjustments I made were to re-bind the keyboard shortcuts to reflect this pattern (e.g. the first workspace is $mod+y, the second workspace is $mod+u, etc.). Re-sizing is also super easy, and so is adjusting layouts with $mod+j, $mod+s etc.
Step 2: Moving around applications. Then came the question of dealing with moving between applications. Coming from Windows I installed Ulauncher which does its job well - just opening apps. But then I learned about rofi and I have since started incorporating it into most process switching although I still haven't gotten the full extent of it. After having retargeted Alt+space and Win+space to Ulauncher and rofi it has never been easier to open a new program.
Alongisde that I started using fzf attached to $mod+b which has been a great way to find files fast without having to perform some targeted grep to the right folders.
Step 3: Terminal + multiplexer. I initially started wit Ubuntu default terminal before watching a video that made so much fun of it that I had to move. So I landed on ghostty although I will admit I barely use 20% of its capabilities, but I never felt the itch to explore more as it does very well exactly what I want - typing and occasionally previewing pngs. Once I started using terminals I realized that it was very important to be able to copy-paste, move around, split panes, etc. which are things that a terminal emulator like ghostty is not best suited for. So I started exploring terminal multiplexers and landed on tmux. I know there are interesting alternatives to a ghostty+tmux option such as cmux that bring the two together but I have not felt the need to explore them so far.
One of my favorite changes on tmux config has been the re-mapping of the leader key ctrl+b to ctrl+j. The reason is again that I prefer to have the second key in the home row of the keyboard and j is perfect since it remains in its starting position so that it's super easy to click the actual key for the shortcut such as ctrl+j+[ for entering copy-mode. Among other things I soon found some struggles with copy-pasting since I was not very familiar with clipboards and how each piece manages their own buffers, and landed in a position where I now essentially copy everything in the default keyboard buffer so that it's always available.
Step 4: Inside the terminal. Once I could move around my desktop and apps it was time to focus on my terminal, with the goal to make using it as enjoyable and simple as possible.
So first came a TUI folder manager (lf) to navigate folder visually in the terminal. Then came time to move more efficiently across folder from the command line, so it was time of programs like zoxide (equivalent of cd but searching across all directories you already visited), rg to search inside files, and some standard linux commands like cat, history, ssh, etc.
When I first started using the terminal I ran in the recurring problem that if I wanted to change the text I had to keep moving around the command line with my arrow and just changing one letter at a time. That was all before I learned about the fact that command lines work under Emacs keyboard shortcuts. If you know vim key-bindings it is probably not worth it to extensively learn Emacs ones but learning the basics can be very worth it (ctrl+b to back one word, ctr+a to go back to the start, ctrl+k to erase the current line, and much more) or alternatively just set vim-keybindings on the comand line with set -o vi.
Finally, if you want to live on the terminal, you will probably need to preview images (ghostty is great for this) and quickly open and change files. And of course there is no better way to modify code or txt or md files than vim, or even better neovim. This is probably the thing that took the largest amount of time to set up. Starting with vim was great: fast, reliable, and effective, but somewhat limiting. So I moved to neovim once (first had to go back because I messed up the config in multiple ways). Moved back to vim and then gave neovim another chance - and oh it was worth it. Now if I want to open any file I could not imagine openining it with anything other than neovim (of course that's where I am currently writing this blog post as well).
Step 5: Browser. One of the beasts you have to fight with a keyboard driven system is the browser. By design, these two things are hard to bring together, but qutebrowser does an excellent job bridging the two. qutebrowser is almost completely keyboard driven and is a pure joy to use. It's eternally configurable and infinitely customizable. My favorite thing is how you can even copy things in the middle of the page without ever touching the mouse by entering searching for the word with /, entering v-mode, and selecting with vim-like key-bindings, and yanking just like in vim. There are some occasions where I have to go back to Google Chrome since I find there are better ad-blocking extensions for some use cases and I have my bookmarks saved there and I am lazy to export them to qutebrowser.
Step 6: AI. I find that I am using AI quite a bit to get quick information or in-depth technical questions for things, so I wanted to have a workflow that would be able to integrate AI well. In particular I installed Openclaw, Opencode and Claude Code. I have found that I tend to gravitate towards Claude Code (which in this whole blog post is the only thing that is not free - with the exception of the hardware) mostly because I prefer the CLI to the TUI Opencode equivalent. And I have not really found many useful use cases for Openclaw yet. Lastly, I tend to use the web version of the AI models quite extensively for general simple questions so I was looking to also make that experience enjoyable and this is where I landed: opening Claude (or sometimes DeepSeek) on qutebrowser and moving across the chat and the answer. Occasionally the section will lose focus for which I have built a script (since you can do this on qutebrowser) attached to the shortcut gs so that it refocuses on the main part and I don't have to click with the mouse; this might seem silly but it has actually brought me piece so many times that I am very happy I took the time to address this recurring small problem.
Step 7: Miscellaneous. I had the core with Steps 1-6 and I was left with some other things to slowly turn around. Spotify became ncspot, RSS readers became newsboat, Obsidian is probably one of the few things that didn't change - although I have tried directly using Telescope within neovim with the Obsidian extension and CLI - Microsoft Office became Libre Office, Adobe became evince (the default Ubuntu pdf reader which I find more than sufficient to do what I need) and to be very honest I don't miss any of the predecessors. I am certainly forgetting multiple things here but these more or less constitute the core of my mouse-less day-to-day use.
Step 8: Enjoy. I have never been happier to use my machine. It doesn't feel like a struggle anymore to actually use my pc, and I find a lot less frustration and a lot more joy in doing so, which is incredibly exciting.
Not an endorsement
I don't actually know whether this keyboard-only search has made me any more productive. In fact, it probably made me less productive since I wouldn't have wasted time writing this blog post otherwise. But it has certainly made me more at piece. At piece that if there is something I don't like I will likely be able to find a solution to solve it, and if not I will feel empowered to build it. This blog post has purposefully blurried the keyboard-driven philosophy with the free software and open source software philosophy because, while not necessarily overlapping, I believe they both stem from the same root of wanting to make the experience of using software better. They of course do it in very different ways, but they generally land on similar conclusions as I found that the best (open source) software is generally also the same that tends to have the best keyboard-driven support. I think overall this keyboard-only philosophy has really helped me to open my eyes to the beauty of free and open source software. Whether keyboard-driven and OSS similarities are correlation or causation I think that's been a win to learn about both for me. If anyone is reading this: thank you, you are really appreciated! And please take this piece lighheartedly, and with lots of grains of salt, since we all know life is too important to be taken seriously.