Don’t Ossify Defaults

Have you ever noticed that default key bindings are just bad? Look at Windows and CUA and control-p being print, still, to this day when printers are mostly irrelevant. For the vi text editor, it made sense for Bill Joy to fill out the keyboard with operations that he had written or could easily write in his available time, to put them conveniently in reach. But haven’t we grown beyond that in the time since? Vim’s default key bindings are strained. You have prime real estate with s bound to the useless substitute-character command, then you have all of these wonky ad-hoc key sequences for much more useful things that you probably don’t use because you can’t remember the keys. As soon as these things are published and people start using them, critical configuration like key bindings immediately ossify. Almost all software has its earliest functionality bound to the most convenient and mnemonic keys, not the most useful. Later features are tacked on with increasingly complicated and non-memorable bindings. Now, years later, we are often left with inflexible software that uses key bindings that are hard to remember, hard to put to good use, and frankly even in the way of innovation and utility for holistic computer use.

Keybindings for programs are not merely bad in isolation, but they are also bad together. There are a few conventions that work between programs, but they are typically terrible. This is a part of why typical computer users only know two key bindings: C-c (control + c) and C-v for copy and paste.

I wish that I could have general OS-level configuration for the common key bindings of apps, plus individually configure every program that has extra functionality that I want available via keyboard. I wish that I could find common ideas to abstract from multiple programs to design key binding patterns between programs so that I can learn bindings once and use them in many places. I wish that people could reasonably provide key binding presets for groups of programs so that many people could design different takes on ways of binding keys to work efficiently with the operating system and its applications as a whole.

But here are a couple of low-hanging fruit ideas that I want programs to do:

(1) Allow key rebinding.

As part of that, allow it in a convenient, easy way. And most importantly, allow it to be configured in such a way that you can save a configuration file, in a text format, that you can keep in version control (eg. with git), separate from other program data or configuration.

Web browsers, please, your key bindings are bad, just let me re-bind them, and do it in a consistent way that is easy to apply to all of my browser profiles on all of my machines.

(1.5) Don’t force default bindings

This is also a plea to emacs package authors: provide a function to enable your default bindings, don’t just activate them by importing your package. The first thing I do when I install an emacs package is typically find the variable names of the key maps defined and clear them out, so they don’t have opportunities to shadow my key binding layout. Mutating the global key layout is the worst offense here.

Even if you have well thought out keys, they may work poorly for someone who uses a non-standard keyboard layout (gasp), or who has thought out an effective key binding scheme that conflicts with yours.

It is easier for programs to not force brittle, ossified defaults if they do the next thing:

(2) Use configuration bases.

Programs that can be configured in powerful ways to fit individual users great staying power (eg. see Emacs, my favorite text editor, which is older than I am). But their default configuration gets outdated. They can’t update the default without breaking everybody’s existing configuration that they’ve been using for years! A fix for this is to have every configuration be based on some built-in base configuration version. Wouldn’t it be great if Emacs required your configuration to start with something like (emacs-base-configuration-2025)? With no configuration, the latest default base configuration is used. But if you actually configure anything, you specify a version (perhaps automatically when using a GUI configuration tool). Then old-timers could use (emacs-base-configuration-1980), while first time new users with no configuration file could have a completely different, modern configuration. All users can then upgrade their base configuration if and when they want to.

To some degree, this is solved with eg. emacs starter kits. But they can’t do everything that ought to be done.

I see many people complain about configurable software, saying that they want software that “just works”, that they don’t have to configure. I want software that “just works” and doesn’t need configuration, too! But “just working” with good defaults is orthogonal to whether or not something is configurable. The key feature that is missing is the configuration base to allow the default configuration to move forward.

In summary, default configurations, including key bindings, should be viewed as just a default option. We should allow defaults to move over time by allowing users to specify which base they are starting from. It should be easy for third parties to publish key binding schemes for programs, or groups of programs.

Thus why I bill the Composiphrase Demo so much as a demo. The core ideas of Composiphrase are great, I think. But the demo bindings are just one way of looking at it and using it. And frankly, many of the bindings were quick decisions to finish the project. Someone else might make a better scheme of keys even if they stick closely to my other decisions with respect to key language grammar.