「次の課題」記事へのコメント

入力システム

[tabatee (1637)]

おひさしぶりの田畑です

フレームワークをフルスクラッチで作る元気はもう無いので、私のロードマップとしては

• ここ [vector.co.jp]にあるim_customにAnthyを追加する
• gtk2やemacsからソースを流用して、いくつかの言語のモジュールを追加する
• vim以外でも使えるようにAPIを整理する
• vim以外のソフトに埋め込む
• デスクトップで状態を共有するためのシステムを作る

なんてふうに考えています。ことによると、APIをvim以外フレームワーク(unicon,libiiimf(風の噂では計画中らしい))のものからとって来るかもしれません。

フレームワークを不適切に設計すると、簡単な言語(ヨーロッパの言語など)の入力システムの実現を複雑化し、複雑な言語(日本語)を収容できない(難しい)という辛いことになるので注意して設計しようと考えています。

Re:入力システム

[kubota (64)]

X 上の入力システムは、現存する XIM サーバがそのまま使えるようなシステムがいいなと思います。ぼく的には、skkinput と xcin と ami が使えればそれでいいけど。

一方、コンソール上の入力システムは、アプリケーションに変更を一切必要としないものがいいと思います。つまり、アプリケーションから見たら、コンソールそのものが入力機能を持っているかのように見える、ということ。たとえば uum とか canuum とか skkfep とかみたいな。emacs とかみたいに、個々のアプリケーションごとに別個の設定が必要、なんてのは、これからの「国際化はあたりまえ」時代に向けて、不適切だと思うので。(国際化アプリケーションがひとつだけ、ならそれでもかまわないけど。)

実際の実装をどのレイヤーでするか ([コンソールそのもの/GNU screen みたいなの/uum みたいなの]/[直接実装/APIを設ける]) については、ぼくは口をはさむだけの意見はもってないけど。

Re:入力システム

[tabatee (1637)]

なるほど、私とkubotaさんのアプローチの違いがわかりました。
私は変換エンジンの側から考えていて、kubotaさんはアプリケーションの方から見てるんですね。

当然どっちも大事なはずなので、がんばっていきましょう。