(TitleOnly)BTRON(超漢字)って、もともと「新JISかな入力」が普及することを前提に設計されていた……のかも。
すくなくとも、標準イネーブルウエアにある「シフトキーの固定機能」(≒現実的には、新JISかなのプレフィックスシフトと同じ挙動*1をする)あたりは、新JISかなとBTRONのどちらが先なのかわからないものの、基本線としては同じところを目指していたのではないかな、と。
新JISかなの規格は「小指シフトキーは除去するな」と言ってはいるけど「親指シフトキーは付けても付けなくてもいいよ」ってのが肝だから、基本的にBTRON環境との親和性は悪くない（＆BTRON環境用のJISかな定義を標準ツールで弄るだけで、新JISかなは再現できる）ので、何か関連性がありそうな気はする。
同時打鍵処理エンジンについて「連続的なシフトの否定(分別)動作」を実装しなかった(＝NICOLA同時打鍵ロジックを再現しなかった)ことは、とても不思議……もともとBTRONはリアルタイムOSなので「普通に組めばハードウエアロジック並みに高精度なソフトウエアロジックになるから、おそらくは忠実に親指シフトハードウエアと同等の精度を実現できる」のだけれど、あえてそれを採用していないッぽい。
もともと「新JISかなとTRONかな」での標準的な挙動を再現するには、それらと共存できるように「押してる間はシフトし続けること」が必要だから、NICOLA同時打鍵ロジックを採用するわけには行かなかったのかなぁ、と。
#TRON環境では「かなモードと英字モードのシフトキーを別々にはしない」くらいの徹底ぶりだから、たぶん同根の考えで「シフトロジックについても和英共用できるものを！」となったのだと思う。
個人的には、BTRON(超漢字)用の擬似同時打鍵ロジックとして「文字キーUp時の交差判定」が採用されたあたりがとっても謎だと思うところ。
わたしのベタベタ打つパターンだと「文字キーDownには気をつけているけど、文字キーUpについては順序が逆転していたりすることがある」から、このロジックだと誤打鍵となってしまう場合があるんですよね……。
もしもBTRON(超漢字)の擬似同時打鍵ロジックとして、新JIS論文方式の「タイムシフト」が採用されていれば、もっと使いやすかったのではないだろうか……と思ったりすることはあるのだけれど、いまさらそんなことを言っても遅いんだろうなぁ。
うーん……超漢字Vで「かえであすか」を再現したときのように、Windows環境でも
- 無変換キーと左小指シフトキーを交換。
- 変換キーと右小指シフトキーを交換。
という風にして、「和英シフトに関する位置＆モードの共通化」を図ってみるテストをする必要があるのかも*2。
このあたりはとりあえず要検討……ということで。
