YamaKen
yamak****@bp*****
2004年 11月 11日 (木) 15:06:41 JST
ヤマケンです。
#[Anthy-dev 1364]に対するレスです。スレッド切れます。
Hiroyuki Ikezoe poinc****@ikezo*****
2004年 11月 11日 (木) 12:39:57 JST
> On Thu, 11 Nov 2004 11:52:16 +0900
> YamaKen <yamak****@bp*****> wrote:
>
> > custom APIとuim-prefに関する開発計画をまとめてみました。表さん、
> > 足永さん、kzkさん、確認と意見をお願いします。もちろん他の方々の
> > 意見も歓迎します。
> (略)
> > - キーバインドの設定に未対応
>
> このキーバインドというのは、変換エンジンに共通のものをひとつ作るということでしょ
> うか? それとも、それぞれの変換エンジン毎?
> 変換エンジンによってその特性が違うので、おそらく変換エンジン毎の設定を作るという
> ことだと思って話を進めます。
>
変換エンジン毎という区分に近いと思います。ただし、以下のように
globalな設定をanthyの設定に流用するというような事も行います。
(define-key generic-off-key? '("zenkaku-hankaku" "<Shift> "))
(define-key anthy-latin-key? '("<Control>j" "<Control>J" generic-off-key?))
たぶんzoeさんの知りたい事はprimeのキーバインド設定だけを別ファイ
ルに分離できるかどうかという事だと思いますが、そういう要求がある
なら分離しておこうと思います。
> 実は、2日ほど前からPRIMEの設定をGUIで行えるツールを作り始めました。
> といっても、まだ画面しかないですが。しかも、風博士からのパクり。
> それで、このツールをuim-prime、scim-prime、おまけとしてgtkimprimeで共通に使える
> ものにしようと思ってました。実際にはツールを共通で使うというよりも、ツールによっ
> て作成される設定ファイルを共有する方がメインですが、その設定ファイルのフォーマッ
> トについて、ここAnthy-devおよびprime-devでお伺いをたてようと思っていたところです
> 。
色々急展開ですね。まだ名前が無いようであれば、以降の文では便宜的
にzoe-prefと呼ぶ事にします。
ところでどこかにスクリーンショットはありますか?
> というわけで、設定ファイルのフォーマットに関してリクエストしておきます。scheme依
> 存はやめてください。お願いします。
先刻承知とは思いますが、一応言っておきます。uimが設定をSchemeの
コードの形で扱うのはそれが最も楽な実現方法でかつ柔軟性があるから
です。これはuimがSchemeを採用している価値そのものなのでまず動か
ないと思ってください。
> uim-hogeでhoge.scmからキーバインドの設定を読むことに関しては別にそれでいいんです
> が、共通の設定ファイルからhoge.scmに落としてから使う、という風にできないでしょう
> か?
一方で、こちらの要求は実現可能だと思います。要はzoe-prefで作った
設定ファイル(以降zoe.confと呼びます)を原本としてuimの世界に対し
てimport/exportできればいいわけですよね?
uim/prime.cあたりにzoe.confのimport/exportを行う関数を作ってもら
えればuim-prefやuim-prime側で適切なタイミングで同期を取る事は可
能だと思います。もちろんSchemeまわりのコードを書く事については協
力できます。
> 今のuimのhoge.scm内のキーバインド設定は他のIM brokerからは使いにくいです。設定フ
> ァイルはもっと単純なテキストファイルにしませんか?
<余談>
IM brokerという言葉は半田さんが使ってらっしゃったのですが、複数
のIMとクライアントを仲介するものとして表現されていたと思います。
IIIMF, SCIM, uim等のIM frameworkが持つ機能の内、特に仲介という側
面にフォーカスしたい時に使うべきだと思います。この場合はIM
frameworkでいいんじゃないでしょうか。曖昧な区分ですが。
</余談>
> たとえば(これも風博士からのパクリですが)、
>
> [Input] <- モード。PRIMEだとFUNDAMENTALとINPUTとCONVERSIONの3つのモード
> delete = 'Delete'
> delete = '<Control>d'
> backspace = 'Backspace'
> backspace = '<Control>h'
>
> [Conversion]
> ...
耳タコでしょうが、Scheme中心の視点で見るとこういったテキストは複
雑で高開発コストなフォーマットです。なのであくまでも
import/exportを通して連携するに留めたいと思います。uim外のツール
や人間が扱う場合には単純だという事には同意します。
> みたな感じで、ひとつの機能に対しての重複エントリが複数キーバインドであるようにす
> るのはどうでしょうか?
>
> ちなみに、モード毎に分けてるのは、モード毎に分けると各キーバインドの処理が分かり
> やすくなるためで、まあ、基本的にはぼくの頭がトリアタマであるためで、別にそうなっ
> てなくても構いません。
今のところはモード無しの方がuimとの間でimport/exportするのが楽な
のでそうなっていた方が楽だと思います。
ただ、今後uimはキー入力まわりでどんどん大きな変更が入っていくの
で、完全互換はそのうち崩れます。具体的にはマルチストローク(C-c
C-x i等)や非modifier key同士の同時押しといったキー入力表現の拡張、
それからコマンドとキー入力の分離に関連してローマ字かな変換等の
compose tableとの融合、例えば直前の文字が子音の時だけ有効なキー
バインドといった設定等が導入される予定です。
#こういった拡張を支えるためにもSchemeコード表現が必要です
zoe-pref及びzoe.confの導入に当たっては、その辺の事情を念頭に置い
て誰にとっての利便性をどこまで確保するかの落としどころの検討が必
要になります。
-------------------------------
ヤマケン yamak****@bp*****