💾 Archived View for asquare.srht.site › gemlog › contingency_complexity.gmi captured on 2024-12-17 at 10:34:20. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
In a previous entry, I've mentioned that I use a script to implement an idiosyncratic set of keybindings for switching window focus. The current version of the script has a streamlined, single-keystroke interface:
Imagine that the screen consists of a 3x3 grid of cells. Observe that a typical keyboard includes a numpad, with its own 3x3 grid of digits. Bind <super>+<digit> to a script that gives focus to the window occupying the grid cell corresponding to that digit's position in the numpad.
The Flipside of Interface Modality
This script has an obvious limitation: if there are more than nine windows open on a single screen, multiple windows must overlap a single cell of the imaginary grid, and there is no way to specify which one of them is the intended target of a focus switch. When I wrote the first version of my script, I thought that this situation might actually arise in practice (spoiler: in four and a half years, this never happened, not even once), so I ought to put some code in to handle that contingency.
In order to support unambiguously specifying one window in the hypothetical (and, in retrospect, ridiculous) situation of the screen being tiled with a very large number of very small windows, I had to loop over an arbitrary long string of digits, subdividing each cell into sub-cells and sub-sub-cells as I go along. The actual calculation wasn't that complicated, but it did add two keystrokes of overhead to the "interface gesture": one keystroke to open a small textbox into which I can input an arbitrary long string of digits, one to enter a digit, and a final one to confirm that I have no more digits to enter.
(I got this recursive subdivision idea from keynav, a nifty little program that lets you use keyboard shortcuts to position the mouse pointer. Unlike my script, keynav actually for real needs to handle arbitrary numbers of arbitrarily small targets, just like a real pointing device.)
https://www.semicomplete.com/projects/keynav/
Two days of actual use were enough to convince me that 200% overhead for the most common case is unacceptable, and I added the aforementioned single-keystroke "fast path". I ended up using this "fast path" exclusively, so later when I had to re-write the script in another language (a story for another time), I implemented only the single-keystroke keybindings. The contingency handling code is gone, and good riddance.