[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:10680] Re: GNU Emacs (Re: Debian JP popularity contest results)
たけ＠阪大です。
From: ISHIKAWA Mutsumi <ishikawa@xxxxxxxxxxx>
Subject: [debian-devel:10673] Re: GNU Emacs (Re: Debian JP popularity contest results)
Date: Tue, 19 Oct 1999 01:13:30 +0900
>＃ちょっと debian-devel な話じゃなくなりつつありますが ^^;;
確かにそうなんですが.....
>>> GIMP (Generl Input Method Protocol) プロジェクトみたいなのを
>>> 立ち上げてみようと思ったりして @_@;
えーっと、この発言撤回です。かんなプロトコルで十分いけそう。
何で GIMP なんかを作ろうかと思ったかというと、
ATOK の API では、読みを一括して送る、ていうのはなくて、
一文字ずつ送る方法しかありませんでした。一方かんなは一括変換が
標準っぽくて、しかたなく、esecanna-atok では、クライアントから
一括して送られた読みをローマ字に直して、一文字ずつ ATOK に送る
という方法をとっていて、従って非常に遅かったんです。んで、
新たなかな漢字変換の API を作って ATOK をフルに生かそうかな、と。
でも、かんなでも、AutoConvert あたりを使えば一文字ずつ読みが
送られてくるということがわかって(Emacs なら、ESC [ 2 8 ~ 5 1 2 で
設定可)、今はその実装中です。
# これを使えば ATOK の変換がマジ速くなるンすよ。まだバグあるから
# リリースせえへんけど。
結論。かんなプロトコルで十分いけるので、GIMP はやめ。
>
> 基本的には esecanna って、「Canna のプロトコルをコモンインタフェース
>とした、IM プロトコルコンバータ」っすよね。そうすると、バックエンドを
>分離しておいて、フロントエンド(Canna のプロトコルを受け取る部分)とのイ
>ンタフェースを明確に定義してやると、
うぅ、頭悪いのでよく分かりません。
結構現時点でも、VJE なら vjeproto.c vjesocket.c vjewrapper.c 、
ATOK なら、atoklib.c atokwrapper.c で分離してるつもりなんですが。
>もっと融通がきくもの(あたらしい IM
>が出てきたときに、対応がすばやく行えるとか)ができそうかなとか、そうす
>ると、各種 IM 用のモジュールを用意して、dynamic loading できる機構とか
>加えたやるとおもしろいかなとか、昨晩妄想してたりしました。
dynamic loading については、僕も妄想したりしました。
> えーと、あとですね esecanna 自体が GPL で配布されることになってますけ
>ど、atoklib が static リンク用のライブラリしか用意されてなくて、ソース
>が用意できないんで、このままだと esecanna-atok の binary の配布が GPL
>違反になってしまうので、すごく困るんですけど。。。
>
> ここで言えば、何人か思い出してくれると思いますけど、Mule with Wnn6
>SDK (のソースが配布されなかったころ)で起きた問題と全く同じです。
>
>＃binary が配布できないので、Hamm JP から Mule with Wnn6 は消えました。
これは問題ありですね。このメールそのまま引用して、
ジャストに交渉してみます。
# むつみさんの発言とあれば、ジャストも考えるでしょう。
>＃わたしは LC99 の実行委員ですよ ;-)
あ、じゃあ、もしかしたら会場で会えますね。
他にも debian な人も来くるんですよね。
そのとき、メンテナになる儀式みたいなのを済ませてしまおうかな。
pgp がどーたらこーたらなんですよね。
# あんまりよくわかってないやつ。
-----------------
武 靖浩
大阪大学医学部医学科 学II
E-mail: redstar@xxxxxxxxxxxxx
ytake@xxxxxxxxxxxxxxxxxxxxxxx
URL: http://plaza.harmonix.ne.jp/~redstar
-----------------