While attempting to get an overview idea of how Kaleidoscope works, I came across the following in layers.h:
Specifically:
…if you hold a key on a layer, release the layer key but continue holding the other, we want for the layered keycode to continue repeating.
Why do we want that? It’s not what happens when modifier keys are released, so why should it work that way with layer shifts? To me, that’s counterintuitive, and I definitely don’t want it unless there’s some very good reason for having it. Is there a particular use case that this was done for?
The primary reason for this were the arrow keys: if one released the layer key a tiny bit sooner than the arrow key, they’d get all kinds of hjkl all over the place. This way, they’ll just get an extra arrow or so. For some of the background, see here, and a couple of the later pull requests that have to do with layers (apologies, don’t have the resources right now to link them all).
I seem to recall we experimented with just masking keys on layer change, but that didn’t feel right either, and as far as I remember, had some consequences we did not deem desirable.
I’m in favor of the behavior that “releasing modifiers and/or layer keys doesn’t change keys that are currently held”. I essentially never hold a modified key, then release the modifier with the intent that the un-modified key should then register. However, I recognize that others can have other opinions.
Also, it’s convenient to hold Fn and (e.g.) J for down arrow, and then be able to release Fn and just hold J to keep going down.
On just about any keyboard, pressing and holding shift, then A, then releasing them in the same order will result in AAAAAaaaa. I don’t see why I should expect something different from layer changes where a key is held down to activate the layer (that’s really what shift does from the point of view of the end user, after all).
I do think it’s reasonable to have a short “grace period” so that if someone releases both keys (almost) simultaneously, you avoid spurious unintended keypresses. In my shift+A example, key repeat rate limiting generally keeps that from happening.
That still strikes me as taking advantage of a bug as a feature, and I don’t want it to work that way, but I won’t try to convince anyone to change it. I’m resigned to having to rewrite Kaleidoscope on my own if I really want it to behave in a way that makes sense to me.
That was, in fact, our original behavior for layer switches. Logically, what you way makes perfect sense. When actual users started using it, they found it to be incredibly frustrating to use.
I’d be happy to look at patches to let the behavior be configurable. My recollection is that there was some difficulty in doing that, but I don’t recall what it was.
IIRC, part of the issue is that AAAAAaaaa is limited by key repeat rates on the host, but when we’re doing this on the keyboard, left arrow to H is treated as a new press by the computer and there is no timeout whatsoever.
I think I’m caught up on the history of this via GitHub issues now. If I got one of those spurious “h” characters, I’d consider that my own error, but it’s clearly reasonable to treat it as something the keyboard should protect against. I’d rather have the held key become inactive, but I really don’t have a problem with the current behaviour. I have been convinced.