undefined | Better HN

0 pointssamatman5y ago0 comments

I've thought about this a lot, because I've bumped up against that limitation a few times when customizing my Erogodox layout.

My conclusion: QMK could do this, or at least some firmware could do this. It's hard to come up with an eloquent way to express it, however.

But there's no a priori reason that pressing shift-1 couldn't be special-cased to instead send shift-2, yielding @. It's all being precomposed by the firmware, after all.

It's too bad, because I have a custom key for delete-back-word, and I want shift-thatkey to send delete-forward-word, but as you point out, I can't. But that's a limitation of QMK, not a fact of nature.

0 comments

jrockway5y ago

You can write code to do that in your process_record_user hook, but it's probably going to be flaky. I would just use a modifier other than shift; people tend to call them "raise" and "lower" and just change the layer. That way everything is in control of QMK.

The disadvantage of using layers is that you can't press the layer-activate key on one keyboard and then press your key on another keyboard. With shift (and OS-level modifiers) you could technically do that. But it's a weird case that probably doesn't come up very often.

j / k navigate · click thread line to collapse

0 pointssamatman5y ago0 comments

I've thought about this a lot, because I've bumped up against that limitation a few times when customizing my Erogodox layout.

My conclusion: QMK could do this, or at least some firmware could do this. It's hard to come up with an eloquent way to express it, however.

But there's no a priori reason that pressing shift-1 couldn't be special-cased to instead send shift-2, yielding @. It's all being precomposed by the firmware, after all.

0 comments

jrockway5y ago

j / k navigate · click thread line to collapse