I've switched to programmable ergo keyboards where there's a whole slew of options (https://precondition.github.io/home-row-mods just covers home row mods)
I've always hated stateful control. Always ripped out caps lock key from my boards (or later figured out remapping), same for insert mode
That's carried over, even with options like one shot mods, & cutting down to under 40 keys (& playing with 28, yesterday received a https://github.com/kilipan/zilpzalp), I still don't find stateful control necessary. More layers, combos, & tap-hold go far
> I've switched to programmable ergo keyboards where there's a whole slew of options
The best part of these kinds of keyboards is they provide each thumb two keys each.
That allows for the keyboards to be much more expressive, as well as not needing the pinky for keys like backspace/enter/esc.
> not needing the pinky for keys like backspace/enter/esc.
Probably not so efficient in terms of WPM, but after my previous issues with RSI, I somehow ended up pressing those keys with my middle fingers instead of my pinkie. Usually multiple fingers hit the key simultaneously, either long finger + ring finger or long finger + index finger.
Requires more hand movement but certainly more comfortable.
I wish I could remove the insert key, but unlike the caps-lock that no application rebinds, insert does get rebound. I wish there was an OS level control "pressing insert by accident should not turn on mangle-my-text-mode".
Aren't layers a form of stateful control?
I think the distinction __s is making is between layer toggles (layer is active between layer key presses, described as stateful) vs layer modifiers (layer is active while layer key is held).
And there are definitely reasons to minimize keyboard state. I've been playing around with programmable keyboards (running RMK in my case) with several thumb keys. My thumb was getting fatigued, so I tried using a layer toggle to avoid having to hold it while using the nav layer. I would hit it by accident and then get confused about why my keyboard isn't doing what I expect ("mode confusion"). That gets awkward, unproductive, and embarrassing real fast. You can display the mode via per-key LEDs and/or an OLED display, but those only help if you actually look down at the keyboard, which is not my habit. (I have thought about using a companion app to display an overlay on my computer's screen when in a non-default layer.)
fwiw, I think most of my thumb fatigue was from using my thumb on modifier keys beneath z/x/c and equivalent on the right, which required folding my thumb underneath my palm. Bad idea.
These keyboard designs have some really interesting ideas, but the ideas aren't all unambiguously good. Some of what are described as thumb keys really shouldn't be used with the thumb. I'm still on the fence about column stagger. I think a lot of the reason people avoid the number row on these keyboards is because the purely vertical reach on a column-staggered keyboard is more awkward than the diagonal movement you make on a row-staggered keyboard. And the idea that column stagger is better because it forces you to use e.g. the ring finger for "c" is based on an idea that it's bad to use the index finger for "c" even with a row-staggered keyboard, and I disagree with that. I also think they're undervaluing muscle memory (or maybe were made for people who never learned to type well on a row-staggered keyboard and are really committed to always using the column-staggered keyboard).
for more info on thumb fatigue: https://getreuer.info/posts/keyboards/thumb-ergo/index.html
My issue was tendon overuse in my fingers, so low force switches & column splay worked for me
(splay is where the columns are not aligned, mapping to the fan out of the human hand, see TOTEM https://github.com/GEIGEIGEIST/TOTEM)
can you please expand on your thoughs on the thumb cluster?
(I have a dactly I kind of finished wiring, but didn't get around to programming it yet)
I'm typing on a SoflePLUS2 right now. It's based on the Sofle v2 design, which is described as having a 5-key thumb arc per side. But I try to limit thumb use to the innermost 2 or 3 keys per side after experiencing fatigue. I use the outermost 2 or 3 as opposite-hand modifiers (ctrl, opt, cmd) and try to pull my whole arm in to use them with the same-column finger, instead of treating them as a thumb key that requires folding my thumb underneath my palm as I keep my hand in the home position.
It seems like many in the ergo keyboard crowd are trying to never move their hands from the home position, and I think that might be a mistake. Use a variety of muscles, avoid unnatural positions. More broadly, my understanding is that the research behind using a tented/splayed split keyboard is solid (better shoulder through wrist positioning) but there's nothing really but anecdotal experience supporting the idea that vastly reduced key counts (and associated need for complex layer setups) or column-staggered layouts reduce pain and plenty of confounders (going from unibody to split simultaneously, maybe switching from QWERTY at the same time too, reducing speed, often learning decent form for the first time, often regression to the mean because people switch when they are having problems).
My previous keyboard was a split with traditional row stagger (Goldtouch) that Google's ergo team advised me to try forever ago. I switched recently because I wasn't liking the mushy feel of the keys, that the two "space bars" weren't distinguishable, that it doesn't have an integrated pointing device, and that after such long use I'd worn down the homing indicator on the f/j keys and was struggling to orient my hands correctly. But row-staggered layout was fine IMHO. Made it easier to learn, to switch between it and other keyboards when I had to, and to hit keys further from the home position.
Here's something from Kinesis, who have been designing split ergonomic keyboards for a long time: https://kinesis-ergo.com/wp-content/uploads/Advantage360-ZMK... search for "If your thumbs are sensitive" and "Guidelines for using your thumbs". And note that while they have keys under z/x/c they do not describe them as thumb keys.
Possibly, depending on how they're activated. If the layer is only activated while another key is pressed, that's not stateful (i.e. no different from yet another Fn key). I'd say that layer toggles and one-shot key modifiers are stateful control, yes.
Personally, I've found that I prefer layer shift keys over layer toggles. It takes more mental effort to track in which layer I'm working than to hold a key while pressing another. The only persistent layer toggles I use is to switch the entire keyset to a different layout (qwerty vs workman vs single-handed, or switch the right half to numpad).
Sort of.
The downside from the 'state' from Caps Lock is you have to keep track of whether it's active or not.
Whereas with layers, typically a layer will only be active if you're holding down some kind of "activate layer" key.
Jef Raskin called those "quasimodes" in The Humane Interface (2000) and was in favor of them.
https://en.wikipedia.org/wiki/Mode_(user_interface)#Quasimod...
Caps Lock is stateful control. The function of the keys changes depending on the internal state of the system. The "Fn" key on the keyboard in the article is also stateful (ish), and defaults to treating the F row as the special macros, rather than just F1-12.
Keyboard layers work more like the Shift key.
Layers are usually quasi modes, i.e. the non default state requires an active holding of a modifier key.
You sound like you would prefer Emacs over Vim.
Emacs key sequences are similarly stateful, and GP may hate that just as much, even if the state is temporary.
For my part, in emacs I would often try ctrl-x-s to save, but miss the x. When I repeat the attempt, emacs register the complete but unknown key sequence ctrl-s-x followed by the start of a new key sequence with ctrl-s. I consider this similarly stateful because the behavior of "ctrl-s" changes entirely depending on what keystroke (if any) preceded it.
I don't like that aspect of emacs, but if you are a heavy-duty editor user it becomes difficult to arrange a consistent set of emacs shortcuts that aren't modal that don't conflict with anything else, because there's so many things you might want to do and so many pre-existing keyboard shortcuts that you can conflict with, not just in emacs but in your window manager. As a simple for-instance, I've got four or five keyboard shortcuts I added in the last year for dealing with the Claude windows in emacs that I've been using (the package defines a couple dozen, it's just about five I use a lot), and I didn't even try to figure out how to make them anything other than "C-c c $something" because it's hard to find somewhere they can go in any sort of pattern that makes any sense and doesn't conflict with anything. Fortunately most Unix window managers seem to leave the Windows key alone, but of course if I try to bring that to Windows it would fail miserably.
I did remap my heaviest hitters a long time ago to single strokes, though. Most notably, start macro, end macro, and replay macro all got coveted non-modal shortcuts.
I mostly agree with GP on stateful controls, but emacs has never clicked for me like vim did. Perhaps it's because switching between modes feels more natural than a simple toggle.
Whereas I cut my teeth on emacs in the early 90's, so modal is what felt awkward. I wouldn't dislike vim's modes so much if it just had one combination insert/append mode that worked like every other editor out there (including a couple other modal editors I've used), but even after adding various hacks to my vimrc to help unify the two modes, I still stumble over the behavior differences in other places.
I really like the composable shorthand of vim's command set though, even if the only one I have in muscle memory is <esc>:wq
Honestly, there are more "modern" editors with even more intuitive flows. Helix being one. I think the ideal editor for me would be something like a mix of Helix's shortcuts with structural regexp like in vis.
> I wouldn't dislike vim's modes so much if it just had one combination insert/append mode that worked like every other editor out there (including a couple other modal editors I've used), but even after adding various hacks to my vimrc to help unify the two modes, I still stumble over the behavior differences in other places.
To be fair, for most values of "every other editor out there," they came after vi (if not after vim), so it's not like vi was discarding existing wisdom.
Actually, there are a number of full-screen editors that pre-dated vi. They were for mainframe operating systems, or were confined to some university or other, or were commercial products for something like CP/M made by some tiny company somewhere, and are largely forgotten; with the last magtapes or floppy discs that had copies of them long since thrown away. Unix and vi, and what escaped UCB, got remembered. But there was other stuff around.
Certainly! I was intentionally hedging my bets with 'most' in "for most values of 'every other editor out there.'" I'd still argue that, for very large values of 'most,' most editors in widespread use today came after vi.
For sure, I'm saying that vi stuck with its design rather than follow the trend of other modal editors that converged on one insert mode, and so did its follow-ups like vim.
I just tried out helix and I'm really liking the features like its single insert mode. Still taking some getting used to, since it's selection-first, not command-first, so `dd` just deletes two chars and not the line. And shift-V doesn't select lines... grr.
I have the same feeling and I use evil-mode in Emacs because of that. It's basically Vim inside of Emacs.
I tried evil-mode for awhile, but it had too many edge cases that behave differently so I went back /shrug
I have my instance set up to enable/disable evil via a keybinding. That way, the edge cases can be handled smoothly. There is also a way to configure evil so that emacs keybindings work while in Insert mode, but not in Normal or Visual mode, if that matters at all.
"I've always hated stateful control. Always ripped out caps lock key from my boards (or later figured out remapping), same for insert mode"
You want some real fun, try the Microsoft Surface keyboard. Maybe they've fixed in a very recent version, but given how long the product line has had this problem, probably not. It has a stateful Fn key. That's right, a Fn key that works like capslock. There is no conceivable way this is a good idea. It means that if you actually want to use both "sides" of the Fn'd keys, you literally can not build muscle memory. If you hold the Fn key and press one of those keys, it'll do the "other" function, but if you just tap the Fn key, including because you had meant to press one of the keys but decided not to halfway through (which happens all the time, you just don't normally notice it because it's a completely normal thing to do that normally carries no consequences), you flip the polarity of the entire Fn key set. Now a normal press and a Fn-press do the opposite things. Until you flip it again.
This is not a "oh, as a multi-decade key user I have opinions about whether key strokes should be 68dB or 72dB" question. This is basic functioning of the keyboard. It's insane.
And, naturally, the key is "magic" and the OS can't see it. While I'm bitching, what is the deal with keyboards on new laptops needing special drivers? What the fuck is so special about your keyboard that you need drivers for it? I'll tell you what's so special about it: stuff you shouldn't be doing anyhow. My OS should be able to see and address all keys so I can remap them as needed. Your stupid special key that does your stupid special thing doesn't need to be a stupid special key. Make it a normal key and trigger your behavior in Windows, not in the hardware. Then I can use your stupid special key at least as a Meta or a Hyper or something. You don't need special drivers to have normal keys, you only need special drivers if you're doing something stupid.
So there's no fixing the Fn key on these systems because it's one of the magic keys that can't be seen by the OS at all, so it can't be remapped, it can't be turned off, it can't be locked into one state, you can't do anything. You're just stuck with a keyboard that, from your brain's point of view, randomly swaps a couple of dozen keys around.
Now I'm also on a programmable keyboard. This guy, to be precise: https://mistelkeyboard.com/products/0a26d32ac1e3b1d2af2896e0... which I split across my chair so I've got one half under each hand when it is resting comfortably. That's something you can't get a laptop keyboard to do.
> While I'm bitching, what is the deal with keyboards on new laptops needing special drivers?
The only laptops I've encountered with this are... Microsoft's. Somehow the Surface folks can't get enough of their critical drivers in-box with Windows to be able to re-install from stock media.
(IIRC it goes even deeper with USB drivers missing, but I gave up on Surface Laptops a few year ago)
I agree about the special keys. There are so many HID usages on the Consumer page for keyboards covering so many things, from application launchers to extra editing functions, and it is absurd how often almost none of them are used in favour of vendor-private usage numbers that then require vendor-specific software support.
I have a mac, and I wouldn't mind a fn-lock feature, but only from a different key combo, maybe fn+capslock. The behavior of fn (media keys or function keys) is a control panel setting, so I could probably whip up something with hammerspoon. But right now I just remap most things in my IDE so they don't require function keys.
Anyway, keyboards have needed drivers since we stopped using BIOS to read them, and fancy keyboards with macros tend to need at least a userspace daemon, but yeah this kind of thing should be as much a commodity as a VGA framebuffer is, something you just shouldn't have to fuss with. Far as I know though, USB and the *HCI zoo pretty much are that, so along with the OS's own built-in support, it should support the basic functionality of any keyboard, and provide standard means for extension. I believe the main reason any company ships a 1GB keyboard "driver" these days is the bundled shovelware and spyware.