メモ。

　昨日の鍵盤、D800iDSのような15鍵盤向けに、「か(ka)」「し(si)」「す(s)」を最下段に追加すれば1.8打鍵/かな未満になる……はず。
　とはいえ、15鍵盤ならば「０」キーがらみを元に戻したい気もするし、かといってそのために「す(s)」を諦めるのはなんとなくイヤだし……うーん。
　#これで飛鳥をやっていなければ、(母音が欠けた「です・ます」の)「す(s)」にこだわる必要性など感じなかったのかもしれないけれども。

　http://pc9.2ch.net/test/read.cgi/mac/1095665219/360-
　Mac用のエミュレータとして有名なTeslaを「連続シフト」対応にして下さった方がいる模様。
　Teslaが動く環境をお持ちの方で、どなたか検証可能な方がいらっしゃいましたら、テスト結果を該当スレッドへと報告いただけますとうれしいです。

　……で、私は「scim_anthy_nicola.cpp」の意味を全く理解できないままで悶えていますorz。
　これは単なる泣き言なのだけれど……「ファイルに書かれている関数や定数をクリックすると、include元の関数構造が表示される」とか、「同じファイル内にあるかどうかに関わらず、ソース群全体の関数枝をツリー構造で表示する」とか、そういった【(UMLのように？)ユースケース図・クラス図・シーケンス図の組み合わせ表現などでプログラムを可視化するツール】とか、【(最新シーケンサのように？)ラダープログラムとシーケンスプログラムの組み合わせ表現などでプログラムを可視化するツール】とか、そういうものがあればいいのになぁ……と。
　プログラムを手書きで記述するとなると、「とても自由度が高い」というメリットと引き換えに「全体を把握できる人にしか使いこなせない」というデメリットが出てくる……から、かわりに「ある程度自由度が高い、という程度に制限される」かわりに「パーツをおいて、マウスでぐりぐり弄って、たまに値やアクションをキーボードから入力して……」という方法でプログラムの元となる「設計図」を記述して、それをプリプロセッサに通してプログラムへと変換できるシステムがあると、より「バグチェックはしやすくなり、誰が書いてもプログラムソースそのものは一定のスタイルで記述される」様になるのではないかな……などと思ってみたり。
　TeXのようなものは「コマンドを覚えれば色々できる」けど、そこまで必要はないよ……という人は「ワープロソフトでなんとかやっている」とかいうのと同じような、そういうプログラミング環境があると便利かもしれない。
　はじめは(かつてC++がCへの変換処理をするプリプロセッサとして実装されたように)プリプロセッサとしての実装でもよさそう……でも、将来的には「図形的表現→実行可能なバイナリ」と直接的に変換できるような仕掛けになるほうが望ましいのかも。
　……って妄想しても始まらないので、とりあえずは泣きながら読んでいるところです。