注意書きを見落としていた。
KC部分は生のキーコード、つまりKC_の形式のやつしか指定できず、
C(KC_)みたいな形式に対応していないと。
うまくいかないキーの挙動からそうではないかと予測して、
マニュアル何回も見て、最後の方にある注意書きに今気づく。…orz
ショートカットマクロ用だから、
C(S(KC_))みたいなキーばかりなんだよな。
その部分はマクロキーに、たぶんできるはず…
(追記 できませんでした)
LTやMTで送信できるコードは、
0xFF以内に限られる、
つまり容量限界があり、
その関係で生のKC_しか送れないくさい。
マクロのキーコードはそれをオーバーしてるのかね。
調べ方がわからんのでわからん。
ということで、キーマップを変更して、
KC_になってる部分をレイヤーキーやモードキーにすることを考える。
本末転倒感…。
https://hkmtyh.com/computer/keyboard/qmk/custom-mod-tap/
LTやMTを使った適当なキーコードをkeymapsに定義する。
ここではLSFT_T(KC_A)を使う。
process_record_user()でswitch caseなどで先ほどのキーコードを捕捉する。
case LSFT_T(KC_A):
if(record->tap.count > 0) {
ここでタップしたときの目的の挙動を実装。
修飾キーはaction_util.hをincludeしてadd_weak_mods()やdel_weak_mods()をsend_keyboard_report()と組み合わせる。
レイヤーはaction_layer.hをincludeしてlayer_on()やlayer_off()を使う。
通常のキーはaction_util.hをincludeしてregister_code()やunregister_code()を使う。
return false;
}
タップの場合はreturnでここまで処理がこないのでここからは長押しの場合になる。
長押しの場合は修飾キー、もともとの処理と同じ処理を実行したい。
trueを返すと捕捉したキーコードのもともとの処理が実行される。
return true;
はあなるほど。
こういう風に一個一個処理内容を丁寧に記述すればいいのか。
そのキーの名前もLSFT_T(KC_SPC)みたいに文法にあってるものじゃなくて、
マクロで勝手にSFT_SPC_Macroみたいに定義したほうがコードの可読性はあがりそうですね。
実際にはC(KC_K)とレイヤーキーを兼ねたいとか色々あったんですが、
実はBasic Keycodeだけでレイヤーキーを兼ねられるような、
うまいキーマップを作れたので、
この手間はかけずに済みそうです。
情報ありがとうございます。
次必要になったらこれを利用します。