2キー同時、3キー同時を多用する薙刀式では、
たまにシフトが入りっぱなしになり、戻ってこないときがある。
(もう一度同じ同時押しをすると復帰する)
これはDvorakJの実装上のバグだろうと思っていたが、
どうやら大元のAutoHotKeyのバグ(仕様上の限界)らしい。
原理が以下に詳しく解説されている。
https://knowledge.sakura.ad.jp/25827/
Sleepを2ミリ秒入れるというヒントから、
DvorakJの設定を以下のように直したらうまくいった。
キーボード/入力全般/待機と遅延の、
「キーを発行する際に遅延させる時間」を、
2ミリ秒に。
動作を機敏にさせるため0にしてたのだが、
これを2にするだけでほとんどバグ現象に遭遇しなくなった。
感謝!
打鍵が速くなってくると、こうした問題も出てくる…
ということで参考まで。
(なお、いまだ「ならないM,MK」をすべてロールオーバーで素早く打つと、
「ならなないM,MMK」に化けるバグは不明。
これも処理速度的な限界か)
DvorakJのソースコード「DvorakJ.ahk」52行目(2014年6月7日版の場合)を
;SetKeyDelay, 0
↓
SetKeyDelay, , 0
と書き換え、AutoHotkeyの「Convert .ahk to .exe」でコンパイルする。
できた「DvorakJ.exe」を使っているものと置き換える。
これは「キーを押してから離すまでの時間」を、「一切時間を空けない(-1)」から「0ミリ秒のSleepが実行され、ほかのプロセスが処理を行うことができる(0)」とするものです。
「ならなない」問題は、キーを離して次に何か押したとき、まだ押したままのキーも押し直されたと見なされるため、のようです。
このとき「濁点」「ゃゅょ」がつくのは便利ですが、「な」はくっつかないので。
私が作ったMac版も似たようなバグがあって、作り直すか、修正で済ますか、ずっと考え中です。
本職登場ですねこれは。
経験的に2msくらい下げてやれ、というのは自分の打鍵がすでにその精度になってるからでは、と思っていたらやっぱそうですか。
とくに3キーロールオーバー以上で発生していたため、
内部的にはめんどくさいことになってるんだろうなあ、
ということは予想していました。
QMKの場合は「まとまった文字列が来たら判定」で、判定がビットになってるので、組合せ爆発が起こらないようになってるはずです(僕の理解があってれば)。
なので原理的にnキー同時押しも行けるのではと想像します。
件のコードでは、他の処理を許容するかしないかの違いということですね。
実はそこまで深くDvorakJの作者は考えていなかったかもしれませんね。
2msスリープが現実的な解だったりして。笑
の書き換え有無の比較を数日かけてやっていましたが、少し悪化するようです。
私の仕事は金属塗装ですが、誤情報を提供してしまい、すみませんでした。
ところで、Win10 の 新MS-IMEを DvorakJ薙刀式 で使う方法ってあるんですね。
DvorakJ設定→キーボード/入力全般/IME 関連 にある
「Google 日本語入力を使用している」をオンにするという……
あらためて DvorakJ のすばらしさに感服しました。
おっと仕事が落ち着いたらDvorakJのソース版手に入れて解読してやろうと思ってたのに、残念。
いずれにせよAutoHotKeyにあるバグくさいので、対症療法ですかね。
Google日本語入力のチェックは気づいてなかったです。
色々奥深いな…