"I don't want to try i3 or Vim. What's the point using less of the mouse? Such a waste of time!"
That was me, 6 years ago. My colleagues were pushing me to try the tools they were already using for years. They are very good developers, so at the end they convinced me to look at them.
I had to admit I was wrong.
I fell in love with these tools. From there, I built my system step by step, configured it as I wanted, according to my own needs. I had the feeling that I was more efficient with it, but more importantly I really enjoyed using it.
Fast-forward 2 years ago. An idea popped up in my mind: what about writing a book to pass on all the knowledge I had about this kind of mouseless development environment? What about enabling every developer to build their own system if they wanted to?
After shortening a trip in Asia beginning of 2020 because of Covid-19, I came back in Berlin without any job or even a flat, only some clothes and my old Lenovo x220. Fortunately, I found a temporary place to live where I decided to write this book.
I've spent hundreds of hours on it, and now I'm really proud to finally release Building Your Mouseless Development Environment, where I explain in detail how to build a similar system to the one I use every day. This system is based on Arch Linux, i3, Neovim, Zsh, and tmux.
The goal is not to impose a particular workflow; I tried to explain every single shell command and piece of configuration for the readers to be able to shape their systems to their own needs.
> If you already know and use all these tools, you won't learn much from the book I'm afraid.
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.
I used Pandoc for the PDF; the links don't work because it's a sample. They work in the real book.
About selling myself short: you're probably right. I'm struggling with imposter syndrome, like many, so I've a tendency to do that. At the same time, I'm trying to be honest and I don't want to deceive people.
your explanation as to why the book isn't 'free or open source' is an explanation that you need money to continue the endeavor while living life successfully.
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.
This gets explained a lot; what doesn't get explained as much is how folks can continue to make money for their work in the "libre" world. It's certainly possible - dual licensing, services, premium editions, physical books, etc., and it's not a bad thing. But my guess is that a "libre" version of this guy's book would rapidly turn into a "gratis" version of it too - a "good enough" PDF would get passed around and ultimately be the main way most people would see his stuff.
I might add that 90% of the situations where I've thought about this in a software context as well have been "libre" -> "gratis" more or less inevitably. Again, there are exceptions, but it's surprising how many people are happy to take something and run with it, no support, no "enhanced edition", no training, etc.
Do we actually know this, for sure? Obviously, it seems like common sense, but there's a similar argument about piracy, and an opposing position that piracy never managed to kill the industries it was apparently a threat to — if anything (so the argument goes), it might have even boosted them. I've bought physical books in the past, even though they were open source. I might also spend money on a digital open source book for various reasons, some of which you mention. It's likely that an author won't make as much direct income from an open-sourced book, but they might make 'enough', even before you consider indirect income.
I was fully mouseless with a tiling window manager (larswm) back in the 1990's. It was very nice, but these days I am very happy with my mouse and graphical tools. Maybe it's senility.
Change is part of life, isn't it? That was deep, I know :D
Seriously, maybe I'll write in 10 years "I was wrong: just install Ubuntu and you'll be happy". It will be a very short book though... but it's good to change and not staying in our little bubble.
For all my years as a developer I've used a dark terminal and vim theme, until last weekend I just couldn't focus with it anymore. Happy with a light theme for the first time in my life
I think there really is something to switching things around every once in a while — color themes, lighting, even where I’m sitting and which way I’m facing.
I think part of is is that varying my environment keeps me more conscious of what I’m doing and helps me avoid falling into ruts of behavior.
I think that's true. It's always good to explore new ways, especially the ones you don't agree with. Even if you still disagree at the end, I'm sure you'll learn something.
I tried Ubuntu a couple of months ago, as well as other distros (elementaryOS, Linux Mint, and Manjaro). For Ubuntu, it's better than before. These distros had some interesting ideas, but I'm still very happy with my system :D
hate to be the devil's advocate, but could you throw some numbers about how your productivity or skill set improved as a direct result of not using the mouse?
I think it's good to be the devil's advocate. Different opinions are great to ask questions about our own.
I don't have any number, that's true. But I know that I enjoy using this system way more than any other I tried (including many "easy-to-use" Linux distros, Windows, or macOS).
As a result, when I discover this way of working, I began to participate way more in open source projects. In general, I didn't only like the result of what I was doing, I liked the way too. It changed everything for me.
I don't think we should always focus on the tools but more what we're creating with them. But if you use tools you truly enjoy using, I'm sure your productivity will increase as well.
This book is not to impose a system to anybody, it's more to dive into Linux and another way of working. That's why I explain everything in details: for anybody to shape their system and swap their tools as much as they want.
Your video was a little too long for my taste.
You maybe could create a shorter video showing the full speed of productivity gained by getting rid of the mouse.
I imagine some workflow every programmer does all the time:
- 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).
That's a good point. To me, the speed is not the first appeal for this kind of system, but more the flow as you say, and it's difficult to demonstrate that on a video :D but I'll think about that for sure.
I have used (and still use) pretty much this same mouseless setup on both my main dev machines; I love it.
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!
Looks great and helpful! Will read the sample more over weekend. Just sidenote: You should put some sort of newsletter box there. Send some tips and occasional promotions -> more sales.
I had a newsletter, and my subscribers were super helpful. Seriously, without them, I wouldn't have finish the book. I thought about keeping the newsletter, but I already had one for my blog. So I simply asked them to switch from one newsletter to the other.
I'm not sure it was a wise decision, but maintaining two newsletter, a blog, and a book was a bit too much for me. I'm still thinking launching a newsletter about mouseless tools though, with tips and tricks; maybe later.
For what it's worth, I think there is a lot of space between what you use and what might work for other people. It's not that there is anything wrong with Arch. Rather Ubuntu is probably easier for many people. The general idea here is Linux.
Similarly, there are several tiling window managers. A neutral description of the options and links to resources might have broader appeal. Text editors are another place where the right tool varies among people.
I guess what I am getting at is "highly opinionated" is better suited for ongoing processes than it is for soft goals. Arch Linux is highly opinionated. This makes reasoning about the ongoing process of maintaining a Linux installation consistent. The strong opinions of Arch Linux are orthogonal to the goal of switching to a tiling window manager. Ubuntu has a different way of reasoning about system maintenance that might offer less friction for other people. Tiling window managers are not dependent on distribution.
I'm not trying to change your opinion. Rather, I think that there are ways to make the book a more useful resource for more people by broadening it to "here's how I do it and here are some other ways that might work better for you."
If I simplify a bit, I see two different approaches:
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.
In my opinion, you're absolutely correct to write a focused, narrow book as that's the only way to stand a chance of addressing a topic completely.
The information available on the internet is vast, as authors it is more often our job to surface, connect, and curate a tangle of information to give readers, as you said, practical direction.
Thanks for that. It's reassuring. I've always tried to do exactly that, and my readers were always thankful for this kind of direction, so... I continue :)
I guess what I am getting at is the vitality of book recommendations not technical merits. There’s nothing wrong with Arch, but I hesitate to recommend it without knowing someone pretty well. The same with Zsh over bash and neovim over Vim.
As personal choices backed by experience it’s a different context than a tutorial for others.
If someone is diving down this rabbit hole, they most likely have some level of tech savvy going in. Given that, they likely can decide if the book is for them by doing some very light research on Linux distributions. With a cursory set of results in hand (which will tell me that Ubuntu is easy and Arch is a bit more advanced but not quite as advanced as Gentoo or LFS), I can decide if a very practical book that says it focuses on Arch is a book that is right for me or not.
For me: I'd LOVE this book. I've been around the block, but don't know everything I know I could. Your criticism doesn't seem to have much merit when clearly there is a market for this book and clearly the potential buyer should be trusted to decide whether this book is right or not.
Thanks! I hope you'll like it! If you have any question, feedback, or problem, don't hesitate to write me an email. It's on the page where I sell the book.
I would tend to agree with that, distros are not that different from one another in the grand scheme of things.
But there are still differences; I speak about them at the beginning of the book. For Arch Linux, the three important ones are for me:
1. Installing it teaches you quite a lot about Linux-based system. If you have any problem with another distro, you'll know pretty well what happens under the hood and you'll be able to debug the problem more easily.
2. Arch is a rolling release, which means that every program you use will be up to date. No need to wait for the next LTS like other distros. It has some drawbacks, but I think the benefits outweigh them.
3. It let you choose exactly what program you want. It doesn't install much by default. Freedom is important for me, and Arch just gives me that.
And did I speak about the crazy amazing Arch Wiki? And the repos which have... everything? Sorry I stop, I'm doing my fanboy here :D
You can find a good middle-ground for example with Manjaro. It has the affordances of Ubuntu, but the power of Arch. I've been using it for a couple of years now, and I'm very happy with it.
I never got the hate of mouse in the dev community. Isn’t most of work browsing code and Googling things? Making a mouse a way to navigate way more efficient than a keyboard? It seems retrograde.
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.)
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.
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.
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.
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.
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.
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.
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)
> 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.
> 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'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.
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
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.
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.
Suggestion: show a sample from your book that is relevant to the purpose of the book. What is currently available as a sample is mostly front matter, Linux fundamentals, and Arch info.
(And also, was it not possible to generalize the information so readers don't have to switch to Arch to follow along?)
I thought about generalizing the information, but if I do that I'll have other problems:
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.
Am I a bad person for buying the book immediately after reading the title? I guessed the arch/i3 setup from reading "mouseless", and after watching the youtube video from the comments I dislike the _specific_ environment but enjoy the fundamentals that led to the environment being built because they remind me of my own journey.
I don't think I'll ever read this book, but I want other people to read it. Actually scratch that, the entire world needs to know this is an _option_. This needs to be required reading in K-12 education systems.
To me you're not a bad person :D thanks a lot for buying it! Maybe you should have looked a bit at the sample and the video before though, I don't want to deceive anybody.
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.
I don't know about you, but when I'm programming I probably spend 95% of the time thinking, so making navigation faster won't affect my overall efficiency much.
Come to think of it, I'm also thinking while typing and navigating so I'm not sure this would save any time at all.
It might _feel_ faster though, which might increase the well-being of some developers.
I didn't write this book for everybody to type crazy fast, I wrote this book for people to try to stay on their keyboard.
You're switching a lot between documentation, your browser, your shell, your IDE, your debugger, and all your tools when you're coding. What I'm describing in the book can really help you not always moving your hand between the mouse and the keyboard.
You think it's not a problem? Well, you should still try to see if you're right. It won't cost you anything: I've many free articles on my blog, linking to other interesting resources too, so be my guest :) I'm sure you'll learn some stuff.
The "95% thinking" trope is fake or I'm really weird, because half of the time I'm navigating/comparing/reading code/docs/tests which would usually involve switching to mouse and looking through taskbars to find the particular piece I want.
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 don't know about you, but for me thinking is almost impossible without writing, drawing, or interacting with some external medium. I can't just sit still and think deep thoughts. This only works for very shallow thoughts.
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.
I'm writing for a long time and I agree with that. But I'll still continue to try producing the best thoughts / writing I can till I'm dead :D maybe I'll never write something good, but at least I tried.
Fighting your tools interrupts thought. A keyboard is a discrete mechanism: you can make mistakes using hotkeys, but the overall state space is infinitely smaller than the continuous state space of a mouse. That makes precision easier, which leads to a closer mapping between intent and action, which makes it easier to enter and maintain a flow state.
I use the laptop trackpad and it feels incredibly natural, not like I'm fighting the tools at all. Two-finger scrolling, three finger swiping, incredibly convenient.
The point is these things are wrong sold. The speed of writing code like you have already noted is already is not biggest bottleneck in software development.
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.
I think it's related to the mouse because the mouse is often used with some type of GUI, and a GUI doesn't allow you to automate the stuff you shouldn't care about very well. Especially when you deal with text all the time.
There are solution for that though, but I find them less convincing than the tools we have using our keyboard. So it's linked, but I agree that maybe this question of mouse / keyboard is not the central one.
This probably depends on what you’re working with, but I never really need to do bulk operations. And moving the cursor a 1000 lines I can do in a second through the magic of two finger swiping and inertial scrolling. Though most of the time i need to go to a particular function, not row, so I’ll just do a quick search.
Surprised to see no mention of Acme here. As much as I love keyboard-based tools, I must begrudgingly admit that from a scientific standpoint it is much quicker to use a pointing device because there is no recall associated with the action, you intuitively drive the device. However that said, there is appallingly little effort to actually utilise this power. Anyway, this is a roundabout way of saying that I don't think mouseless development should be celebrated. Good on him for figuring it out, but did we really need to figure that one out?
I don’t understand this at all. No matter what happens, my hands are mostly on the keyboard. Moving to the mouse is wasteful, and just the act of aiming for it involves more recall than remembering any common key binding. Plus the mouse can only point at or navigate to things on or adjacent to the screen. If I want to navigate to a symbol not on screen or run an arbitrary command then resume typing, I don’t see how the mouse helps me go faster. What workflow are you picturing here that a scientific standpoint backs up?
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.
It's intuitive because you're used to it. I thought the same, till I tried different ways.
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.
All I can say is that the medieval plague was spread by rodents. We are back in plague conditions. If ever there was a time to avoid the mouse, this is it!
Definitely going to check this out! I got fascinated with mouseless interaction several years ago, even to the point that I registered tyrannyofthemouse.com:
Unfortunately, I've had to give up on it for web browsing. Too many sites break the ability of my extensions to pick up clickable elements. I can probably find a long-term workaround, but I'll have to get up to speed on low-level details of what's going on.
Working strictly from the keyboard -- if and when it's possible -- is one way that I can really get "in the zone" and very productive.
In Firefox, by default, you can search for text of an element using forward slash. Then you hit escape and hit enter to activate it, or tab to navigate past it. That alone made 90% of websites practically mouseless for me
I just tried that, and while it does select the element, it still doesn't allow me to click on them as you suggested or any other way I could find[1]. (That is, it works in general, but only on links where my extension would be able to pick up the clickability already.)
[1] Example: clicking on a currency here [2] or a time window here [3].
It seems the site is actively preventing it somehow. It might enable clicks only after onmouseenter or onmouseover events. You might want to try simulating them. It also might register onkeydown events that catch pressing enter key on them. You might want to disable those.
Additionally some sites register click events on parents higher up in the DOM tree and then determine the child/spot under the cursor. That forces you to supply some coordinates yourself.
Yes, on reddit it's been kind of a guessing game to determine whether the clickable element I want to extension-click is the parent or the child that it detects.
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.
Help me understand. I’ve always felt the limiting factor for me was the speed of thought, not typing or other text manipulation. My IDEs (Jetbrains stuff) with their defaults makes it so I spend more time thinking than typing. Often times my best work occurs in the shower, or on a walk and has nothing to do with keyboards or mice.
On occasion, I need to do something highly repetitive in which case I’ll do something on the command line (with sed, awk, and peers) or I’ll open the file in vim, record a macro and apply it appropriately.
Am I missing something? Am I a weirdo or a dummy in that I’m not itching to type faster and interact more efficiently?
I'm not itching to type faster either, so we might be both weirdo :D
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.
Quick practical tip: "turtle your mouse". We all know we should probably learn more keyboard shortcuts to be more efficient, but it's hard to have the discipline to practice them when we're busy and the mouse is so easily accessible. My hack for this is to "turtle" my mouse: flip it upside down so it looks like a turtle on its back.
This introduces a tiny bit more effort to using the mouse - you have to flip it over first. I find adding that little bit of resistance makes me much more likely to learn keyboard shortcuts, which in turn make me more efficient overall.
I've been meaning to finally upgrade from my ancient but perfectly functional Linux Mint 18.3 (based on Ubuntu 16.04) to Regolith Linux, with the intention of getting into an i3 environment.
Any thoughts or comments about Regolith?
EDIT to mention that for people interested in getting into tiling window managers (such as i3), the Pop_OS distro also comes with its own, optional tiling wm that can be switched on/off, which might be a nicer and more approachable middleground for newcomers
Not OP, but I swapped over to Regolith a couple of months ago on my laptop and now it's on my main workstation too. Coming from Ubunutu MATE on both. Very happy with it.
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.
Sane defaults is key. I've seen lots of comments about how nice i3 is, but also about how it's a rabbit hole of small config changes until you reach some nice settings.
I like to adapt myself to default settings instead of the other way around, because that allows me to seamlessly move between workstations. So a carefully selected choice of default settings is a very nice thing to have.
I think a lot about mouseless computer interaction myself as I am making KeyCombiner[1], which is an application to organize, learn, and practice keyboard shortcuts.
Among many other things, it can map collections of keyboard shortcuts onto a virtual keyboard. This helps immensely when looking for free combinations or conflicts, which is often the case with VSCode and Neovim. You can have a look at the public VSCode collection[2] to see the visualizer in action.
KeyCombiner's concept of building your own shortcut collections could be very handy for your proposal to create your own cheat sheets. With KeyCombiner Desktop[3], you can instantly look up these cheat sheets. In addition to your own collections (cheat sheets), the instant lookup always shows the default keyboard shortcuts of the active application.
For both there are shortcuts already available for a "command" input. For example in IntelliJ it's called "Actions" - you can use it to look up basically any command/functionality from there.
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.
Nobody has mentioned keynav[0] yet. "It lets you move the pointer quickly to most points on the screen with only a few key strokes."
With some software or web pages you're better off with this kind of workaround than installing browser plugins or configuring the software, especially if you use them infrequently.
Another tip: use ' in firefox to search for links when the focus is not in a text area. For instance, typing |'comment| (without the pipes) here selects a link containing "comment", and you can circle through other matches with F3 / Shift-F3 just like regular searches.
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.
Yeah that's a good insight. It is more like its own os than a pipe in a system, though you could use it that way too. I've fallen in love with elisp and tools like org. Take a look at doom emacs and oxhugo package if you want to take a spin again. Org-roam might be something else that resonates for you.
Massive popularity of Indian accounting software tally is because of mouse-less handling of the whole interface. Mouse uses three organs while keyboard uses only one.
Many of the older core banking systems were keyboard only, because it made the tellers work a lot faster.
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've been finding zsh to feel extremely bloated lately and killing my workflow. Mainly because I use oh-my-zsh with several additional plugins, and also because I use guake with at least 10 terminal tabs open at any time. Zsh has some strange refresh issue when SIGWINCH is called to switch back to the guake window that results in more cpu usage when switching back in the longer zsh is open for. Has anyone experienced something similar?
Every time i have to use mouse heavy interface I just lose the motivation. It feels like in GUIs you just spend most time searching things, while with cli and plain text files you can easily search existing examples and documentation for reference while typing whatever you want to accomplish. Recently I had to work with Unity and it reminded me how I loathe monolith integrated workflows.
Just picked up a copy. I’ve been using regolith on Ubuntu for about a year and love it. I like the idea of being able to put together a similar environment, while not needing to get neck deep in figuring out configuration and gory details. Your book basically covers all of that, and checks another box I’ve been interested in (arch). Sweet spot, thanks for the book!
Thanks for picking it! I hope you'll like it. If you have any question, feedback, or problem, don't hesitate to reach out. I'm always happy to help and I'll try to answer as fast as I can. My address email is on the page where I sell the book.
I switched to this kind of mouseless setup a couple of years ago and haven't looked back.
It takes some time getting into, but the rewards were worth it for me. I'm now relying on muscle memory for navigation, and my mouse arm inflammation is gone!
If I was going to go mouseless, it would be to just use a touch screen. But then I'm much more keen on front end stuff. It would have to find a way to decrease the amount of inputted text right down though.
I want mouseless everything. Unfortunately mouseless browsing isn't easy and mouseless usage of the rest of the apps is next to impossible because of inconsistent hotkeys (except on Mac perhaps).
I'm so glad you wrote this book. The benefits seems small - 3 seconds here, 6 seconds there, etc. but compounded over decades, it makes a huge difference.
You're welcome! I hope you'll like it! If you have any question, feedback, or problem, don't hesitate to reach out. My address email is on the page where I sell the book. Always happy to help!
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.
I know it might sound surprising but I don't use that much Stack Overflow anymore :D I'm using the shell for many things, and the documentation is so good I don't need to go on Stack Overflow.
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.
I use a vim keybindings extension [1]. It allows mouseless browsing of most of the good parts of the web. Notably, it adds a keybind that labels every hyperlink and interactive page element with a sequence of characters you can type to open the link.
Depends on your keyboard, mouse and overall desk setup. Myself and a coworker use Ergodox keyboards to combat arthritis and carpal tunnel, but if you're using a standard keyboard and terrible posture it might be worse.
That's interesting. My setup is pretty standard, but with the millions I'll do with the book (ahah) I think I'll try an ergonomic keyboard. I put Ergodox in the "stuff I need to check". If you have any other recommendation, please don't hesitate to share :)
Before you get an ergodox, make sure your desk height, chair position, monitor height, etc. are as good as you can make them. I've resorted to using stacks of books when necessary :)
Yes. I tried to explain every single command as much as I could. The reference is still Arch Wiki though, and it's very good, but I find it difficult to follow if you never installed it before...
I'm using Arch Linux for 6 years and I've my own install scripts I describe in the book. I didn't have to change them very often.
Even if I love the Arch Wiki, the problem is: it's not tailored for beginners. Now, you could say that Arch Linux is NOT for beginners, but I think everybody should make their own mind. I think people are smart, even if they're beginners.
But you're right, sometimes the install change; that's why every update of the book will be free. I'll try to keep up with Arch Linux last updates.
Agreed. But the thing is: What’s a beginner ? I’m a software engineer, been using Linux ( Ubuntu, Fedora) for almost 10 years and when I tried installing arch following the docs I still ran into issues I couldn’t solve or instructions I wasn’t sure about.
i dont like typing. it is a waste of time and very slow and error prone method at least in my case. i have too big fingers and i make too much spelling errors(not related to fingers). i developed my own style copy/paste/search/replace method. simply i just copy paste tons of code(you cant type so fast) and replace names. removing redundand code is faster then typing new one :) you are not bored typing for the milionth time a for loop? :)
dev environments suck with mouse, because people talk things like that(that mouse sucks and that you have to keep your hands on keyboard) and by that no one is spending time on developing dev environments for the mouse. and they are really flawed in this matter. vim and emacs suck at using mouse so please dont say mouse sucks. those editor suck at that.
for years i was looking for tools good for my style of work until i figured out that no one makes them and my coding style is completly different from the one for which the tools are made for(i think people sit and type in the code as they go). you can find in many places that to be a dev you have to write code. that to be cool dev you have to type and use vim and there is no other way. which is bullshit. you want to make software faster? you have to operate on big chunks of code and not a single lines. the snippets suck also - you have to know them and interface is often clumsy by default. most of the things you have to remember(i think that makes being a dev hard). why we dont have starcraft like interface to dev?
You could have already asked me if breathing makes me bored.
when i go ona a bike trip, i dont like wasting time on going through the neighborhood i know. so i take the train and go up to the more interesting part of the trip and have fun. do you know this trick?
also, i use i3, tmux, emacs and vscode on daily basis. i changed my unix experience(mostly cli) into something close to a roguelike game - shell scripting + fzf + make + direnv can make cool things together. the less typing the better, and faster.
That was me, 6 years ago. My colleagues were pushing me to try the tools they were already using for years. They are very good developers, so at the end they convinced me to look at them.
I had to admit I was wrong.
I fell in love with these tools. From there, I built my system step by step, configured it as I wanted, according to my own needs. I had the feeling that I was more efficient with it, but more importantly I really enjoyed using it.
Fast-forward 2 years ago. An idea popped up in my mind: what about writing a book to pass on all the knowledge I had about this kind of mouseless development environment? What about enabling every developer to build their own system if they wanted to?
After shortening a trip in Asia beginning of 2020 because of Covid-19, I came back in Berlin without any job or even a flat, only some clothes and my old Lenovo x220. Fortunately, I found a temporary place to live where I decided to write this book.
I've spent hundreds of hours on it, and now I'm really proud to finally release Building Your Mouseless Development Environment, where I explain in detail how to build a similar system to the one I use every day. This system is based on Arch Linux, i3, Neovim, Zsh, and tmux.
The goal is not to impose a particular workflow; I tried to explain every single shell command and piece of configuration for the readers to be able to shape their systems to their own needs.
If you're curious, you can read the first 30 pages of the book, including the whole table of content there: https://matthieucneude.com/building_mouseless_environment_sa....
If you want to know how this system looks, I've made a short video (https://www.youtube.com/watch?v=67lbLKTm91U) describing the one we build in the book.
Last thing: If you already know and use all these tools, you won't learn much from the book I'm afraid.
Any feedback, positive or negative, is welcome!