飛鳥入力法=「飛鳥カナ配列」+「飛鳥制御配列」
(参考: http://ameblo.jp/asuka-layout/entry-10038301670.html )
ちょうど、鈴見咲さんの【姫踊子草入力法=「姫踊子草かな配列」+「姫踊子草制御配列」】と同じように、飛鳥にも制御配列がある……と。
ただしこちらは「キーボードによって柔軟に変わる」ので、制御配列というような固定的なものではなさそう。
Colemakでは「Aキーの左隣はBackspace」なのだけれど、飛鳥ではそこはEnterであり、Backspaceは「カタカナ/ひらがな」キーに割り当てられる。
「飛鳥カナ配列」のキー定義は、最右端の一列が「なぜこんな割り当てになっているのだろうか……」という気がしていたのだけれど……もともと右端部分は使わないで、他の用途に割り当てる様になっていたのかもしれないですね。
……で、とりあえず東芝ノート鍵盤にマッピングしてみるテスト。
半 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | − | , | ||||||||||||||||||||||||||||||||||||||||||||||
全 | { | ! | [ | ” | ] | # | } | $ | ゛ | % | 無 | & | ’ | 無 | * | ゜ | ¥ | > | / | < | + | = | ^ | _ | ↓ | Bk | Sp | |||||||||||||||||||||||||||||||
Ct | rl | 「 | ー | に | ぴ | % | − | ・ | と | は | ば | 」 | ||||||||||||||||||||||||||||||||||||||||||||||
ざ | ( | え | ぱ | ね | れ | ぁ | ぺ | ぅ | & | ぇ | ぢ | ぃ | 〜 | よ | そ | ふ | こ | ! | ぞ | ) | ご | ← | ||||||||||||||||||||||||||||||||||||
En | t- | き | し | う | て | ぎ | ゆ | ん | い | か | た | ほ | ||||||||||||||||||||||||||||||||||||||||||||||
er | だ | わ | ち | お | あ | な | り | ら | ぉ | づ | ず | ぬ | る | く | す | の | ま | つ | で | さ | げ | ろ | ↑ | Ta | b | |||||||||||||||||||||||||||||||||
S | hi | ft | ぽ | け | じ | ぶ | へ | ゃ | っ | ょ | ゅ | め | Sh | i- | ||||||||||||||||||||||||||||||||||||||||||||
ぜ | ぷ | ひ | べ | せ | み | び | ぐ | ヴ | * | や | む | が | を | 、 | ど | 。 | も | ? | ぼ | ft | → | |||||||||||||||||||||||||||||||||||||
Ct | rl | Wi | n | Al | t | No | Co | nv | Sp | ac | e | Cn | ve | rt | Ka | na | Me | nu | Fn | Pg | Up | ↑ | Pg | Dn | ||||||||||||||||||||||||||||||||||
左 | 親 | 指 | 空 | 白 | 右 | 親 | 指 | Bk | Sp | Ap | p | ← | ↓ | → | ||||||||||||||||||||||||||||||||||||||||||||
姫踊子草/繭姫の単独でマッピングできれば、実際にやってみたいところなのですが……「ひらがな/カタカナ」キーがらみはどうにもならないので、うちでは制御配列を実装できそうにないかも……。
最低限の制御配列交換をするのならば、こんな感じで調整すればいい……のかも?
物理キー | 割り当てるべきキーコード |
---|---|
CapsLockキー | Enterキーコード |
Enterキー | Tabキーコード |
Tabキー | Ctrlキーコード |
Ctrlキー | CapsLockキーコード |
物理キー | 割り当てるべきキーコード |
ひらがなキー | BackSpaceキーコード |
BackSpaceキー | ひらがなキー |
もしもCtrlキーがそのままでもいいのであれば、もう少し端折ってもいいのかも。
物理キー | 割り当てるべきキーコード |
---|---|
CapsLockキー | Enterキーコード |
Enterキー | CapsLockキーコード |
物理キー | 割り当てるべきキーコード |
ひらがなキー | BackSpaceキーコード |
BackSpaceキー | ひらがなキー |
今回の「21c345→21c356」による大戻りにおいて、肝心なポイントは2つあると思う。
- 頻出和文記号系は「頻度の低いカナよりは優遇されていないとマズい」ということ。
- 大きく振る試験を繰り返した上で、はじめて元の位置の妥当性が検証される、ということ。
2つ目は21c290以前からも度々あったような気がするけど、21c290以降では特に増えている印象を受けていて、こういうところからも「文字があるべき場所に近づきつつあること」が窺えます。
1つ目は、カナを優先して3段31キーに配置して来た「親指シフト」との、方針の違いを明確にしているのかもしれないな……と。
(1シフト式でもともと余裕がない新JIS系は別とすると)2シフト式の配列なり、JISかな系であれば「シフト側などに文字を配字する余裕はまだある」ハズなんですよね……。
いまのJISカナでは見る影もないですけど、もともとカナタイプライタ時代には「ホーム段シフト側には数字があった」りするなど、けっこう積極的にシフト側を使っていたわけで……飛鳥の場合、その考え方をカナ記号系に割り振ったとみなすほうが自然なのかもしれません。
かえで携帯配列を使っていても思うのですが、この【頻出和文記号系は「頻度の低いカナよりは優遇されていないとマズい」】というところは、とても重要なことだと感じています。
かえで携帯配列では、優遇というほどいい位置には配字出来てはいません……が、入力モードを変えることなく「カナと同等のコストで」記号系を出せるというのは、自由に文章を書こうとするには、どうしても必要なことだと思いますし。
カナ記号系を低頻度カナよりも優遇配置している例は、他にはそうないはずですから……ここは飛鳥における「コンセプトの一つ」といえるのかもしれないですね。一度実験をした上で、今の位置に戻ってきたというところは、従来の配地方配置方針が「間違ってはいなかった」ことを肯定する材料になりそうですし。