I’m posting here because I have nowhere else to post. If you squint, this meets the community rules because my current keyboard is a Piantor/42, and my issue stems from a combination of 40% and QMK behavior. Although, to be honest, this is mostly about QMK, but using Discord is painful, and I’ll go there only as a last resort.
For a long while, I used Kanata on my laptop, and desktop an ErgoDox, having replaced kmonad because of one certain feature: tap-hold key sequence behavior. It’s best described here, but the tl;dr is that (press lsft) (press a) (release lsft) (release a) where a is a tap-hold key should output “A” and not “a” – kmonad outputs “a”.
A few months ago, when I got my Piantor, I discovered that this sequence outputs no character, and although there’s an option that makes it output “a”, I can’t find a combination that makes it output “A”. I’m asking whether, in the bewildering set of QMK variables, is there a way to configure QMK s.t. the sequence (press lsft) (press a) (release lsft) (release a) outputs “A”?
That’s the main thrust of my question. As a sort of addendum, I think this behavior is behind another of my QMK irritations: I’m a reasonably fast typer, and often will be typing the next key before I’ve completely released the previous key. This means I have to set a large-ish time-out before tap-hold engages, which introduces an annoying delay whenever I want to chord a layer and get at, e.g. numbers. I do understand that this is may be an unsolvable issue, that it’s just an unavoidable limitation on small keyboards in having so many common keys (numbers, punctuation, and arrows are the worst – coding, nearly half the text are characters from layers). Either I have a long timeout and and live with an annoying delay when I want to type (many) punctuation characters or numbers; or I have a short timeout and frequently accidentally shifting layers. However, I feel as if this might be mitigated somewhat with the Kanata-style key sequence handling, because even though my Kanata configuration is nearly an exact mirror of my QMK layer configuration, I never have this problem with Kanata.
I suppose I could give up on using QMK for anything except the most fundamental mapping, and use Kanata instead. However, there’s an appeal to the portability of having the programming in the keyboard itself; it makes me a little less dependent on the computer to which the keyboard is attached.
You must log in or register to comment.
It looks like the feature is called Auto Shift in QMK/VIAL (I had to open up VIAL to remember the term).
I’m not sure I have a good answer for quick typing, I was in the process of implementing urob’s timeless homerow mods for ZMK when I fried my ZMK board. I know there are QMK implementations (maybe in userspace?), but my quick googling didn’t come up with what I was thinking.
For QMK, my go-to hrm-embetterment came from Achordion. Not sure if that helps OP, but it made hrm amazing for me, and it does the sort of timing tweaks that might help here.
Otherwise, the HOLD_ON_OTHER_KEY_PRESS mode might help.
Thanks for the suggestions.
Auto Shift is a neat idea; I suspect adding yet another delay factor would be counter-productive, for me, though. The whole shift/press/release-shift/release-shift issue is more about typing faster than my brain actually works, such that I’m not always consistent in which order I release keys. Adding a lag to get caps would be, I think, infuriating.
However, the timeless homerow mod looks fantastic. Need to think a little more about their solution, but it’s encouraging in that (a) they sound like they have exactly my problem, and (b) they found a solution for it. It’s a great resource, thank you!
QMK has pretty extensive documentation that I’m pretty sure covers this. Have you read Tap-Hold Configuration Options?
I… had not. The permissive hold option looks like it might address my second issue, that of the fact that the fixed timing is incongruent with my far less consistent human timing.
Someone else mentioned the timeless homerow mods, wherein
positional hold-tapis used to address rolling issues, which is what I think I’m seeing with the shift-down/char-down/shift-up/char-up sequence not outputting the expected shifted character.Thanks for pointing me back at the documentation. TBH, I’m a bit overwhelmed by the number of configurable options in QMK, and suffer information overload: pointers like that help me figure out where to start fiddling. Working with QMK, even through the incredibly convenient Vial application, makes me feel like sitting in front of a Moog synthesizer.
