becoming a keyboard shortcuts lover
lowercase thoughts on tranquility in digital existence
earlier this week my recurse friend lucy finally convinced me to try emacs. for the uninitiated, emacs is an older text editor people mainly used/use to write code, first released in the mid-70s. (this was also about around when personal computers with mice were first created, but the mouse didn’t catch on until about the mid-80s, according to wikipedia.) because of this, emacs relies heavily on keyboard shortcuts for things we understand today to belong to the domain of the mouse/trackpad, including, but not limited to: text navigation, text editing, and general application navigation—not just text input. there is a whole slurry of commands for actions like scrolling, text selection, swapping out active files/windows, copy-pasting, and playing tetris, plus a whole host of other things i have no idea about, having only begun my emacs journey recently.
i knew about editors like vim/emacs for a while, but they had always remained firmly in my mind as “things that people who are really nerdy about computers enjoy probably because they are interesting/habit rather than useful in the modern age”. they did not seem like applications that might provide value to me: someone raised in the age of mice and graphical user interfaces (guis), already used to the low learning curve modern code development applications like visual studio code provided. i could just click on a graphical representation of a file tree to get to my file; why should i memorize an esoteric sequence of commands to summon it?
when i first began reading the emacs tutorial i was extremely bored, and mildly annoyed. there were no pictures, no shiny buttons, and no pretty modules with exercises i could do to test my knowledge. it was just a black-and-white text file that was itself the tutorial—to finish it, i was encouraged to learn the emacs way of apprehending the file. even the arrow keys were discouraged; instead i was supposed to use ctrl+n[ext], ctrl+p[revious], ctrl+f[orward], and ctrl+b[ackward] to even make my way to the next sentence. it felt like learning how to use a computer all over again. it felt humbling.
when i finished the emacs tutorial, i was more curious about the world of keyboard-driven applications, for sure, but still fairly certain that this was a one-off experience that i would forget about after i went back to vscode. i had spent the last couple of hours learning things like: how to parametrize operations (like selecting 10 lines instead of 1); how to jump between files, screens, and windows; how to yank and kill (similar to cut and paste); and a bit about emacs’ system of undoing1. it was interesting; it was new. but it did not feel life-changing, at first.
after quitting emacs (not using cmd+q, but ctrl+x ctrl+c!) and returning to the blissful world of lovely little buttons i could press with my cursor, i still felt strangely possessed by the ghost of emacs, compelled to figure out ways to navigate other applications with just my keyboard. i can’t entirely explain it—i’m sure part of it was that i’ve been having trouble lately using the mouse for long periods of time due to ergonomic reasons, but part of it was also just a small giddiness at being able to discover ways to manipulate my computer with keyboard shortcuts. it felt like i was uncovering little hacks. it felt like solving a puzzle, to try to get from point A to point B without moving my fingers from the home row. and it felt exciting to try shortcuts i learned from application X in application Y, and realize that they behaved analogously.
it’s not really possible to interface with the modern computer with only the keyboard—or rather, it is (consider: people who use screen readers), but there’s a point at which it stops being elegant. however, the keyboard is a much more powerful tool than i previously understood it to be. i started my keyboard shortcut experimentation on zulip (a slack-like chat client we use for recurse) which has excellent support for keyboard navigation. most of the time, i can jump to the topics or messages that i want to see, and quickly perform actions like updating, responding, and reacting to messages, all without leaving the home row.
i recently started using the arc browser, which also has excellent shortcut support—actually, the first section in their resource center is on keyboard shortcuts, which kind of tells you a lot about their design philosophy. arc has helped me tidy up my brain when it comes to interacting with the internet: these days, i tend to full-screen whatever tab i’m on, only revealing the browser gui when i absolutely have to, usually opting to move between tabs and open new ones with shortcuts. (i know other browsers have this functionality as well, but i feel that arc is the first one i’ve used that actively wants to “get out of the way”, and there are a lot of other things they’re doing unrelated to shortcuts that i like, which is potentially a separate post.)
this brings me to the thing i wanted to write about in the first place, which is digital tranquility. the advent of the gui has made it infinitely easier for everybody, not just programmers, to use the computer, and i still love using guis, of course. however, navigating my computer with keyboard shortcuts, and minimizing the gui whenever i can, has imbued my digital experience with a sense heightened focus, born from (1) sweeping away all the unnecessary information on my screen, and (2) forcing me to ask, very specifically, what do i want to do next?, rather than aimlessly tabbing and clicking.
browsing the internet without the visual reminder of every single tab i have open is incredibly soothing. it frees up so much working memory to dedicate to the actual task at hand. it also makes it harder to get distracted and just aimlessly click on shiny icons when i’m supposed to be doing something like, oh, i don’t know, writing? when i want to open up a new tab, i have to actively ask myself: what do i want to search right now?, rather than just clicking on whatever social media site my browser knows i visit often. similarly, i’ve been application-switching with my mac’s spotlight search, which allows me to type in the name of my desired application to get to it. doing this instead of zooming out to look at all my opened applications, surveying all of them, and then selecting one, circumvents the scenario where i try to look at vscode and then get distracted by discord instead. operating my computer with the keyboard has forced me to pause and get intentional.
this post is not a prescription. i don’t think the only way towards digital clarity and stillness is through accidentally getting inducted into the cult of emacs. this post is, instead, a collection of musings about the ever-shifting nature of human-computer interaction, specifically focusing the lens on what the mouse did for user interaction. i don’t want to go back to a mouse-less age—the kind of expressivity that it affords is absolutely crucial for the kinds of software people are building these days—but i do want to take “advice” from said mouse-less age. for example, i’m probably going to keep being a vscode user, first and foremost, but i’ve downloaded an extension that allows me to use emacs keybindings to manipulate and navigate my files.
ultimately i am also interested in interrogating the “normal”—what we understand as “normal” hci is not some unchanging paradigm delivered fully-formed from the mouth of god, but a built system that continues to be built and transformed. new technologies tend to provide us more freedom to manipulate digital spaces, but the constraints under which old technologies were developed force a certain level of thoughtfulness: when faced with a limited array of choices for what the user can do next, what do we provide them with? i am endlessly curious and excited to see what the future of interfaces holds, but i am also always eager to examine design decisions that came before. and i think being thoughtful and adopting patterns that work for you, no matter the year in which they were developed, is an excellent way to cultivate a flourishing digital life.
largely irrelevant aside: the gist is that the undo itself is an action that you can undo; because of this you can recover actions that would be written over in other applications. in other apps, if you did an [action A] —> [undo] —> [action B] sequence, [action A] would get stricken from the record. but not in emacs!