[Anthy-dev 308] Re: uim 0.1.6 released & freedesktop.org

Zurück zum Archiv-Index

TOKUNAGA Hiroyuki tkng****@xem*****
2003年 12月 2日 (火) 06:44:58 JST


On Mon, 24 Nov 2003 15:04:51 +0900 (JST)
Konosuke Watanabe <nosuk****@csc*****> wrote:

> とりあえず手近な一人に聞いてみました。やはり感じるのは 1. の
> ひらがな入力のようです。
> 
> といっても実際にタイピングに画面表示が遅れてくるというわけで
> はなく、平仮名を打っている際に、子音部分がちらちらするのが目
> について、入力がもたついているような感じがするとのことでした。
> 母音だけ打っているときはもっさり感は無いとのこと。
> 「これ、反転じゃなくて下線にならないんですかねー」だそうです。

 しておきました。

> 休み明けにもう何人かつかまえて聞いてみたいと思います。

 よろしくお願いいたします。


On Mon, 24 Nov 2003 16:51:27 +0900
Mamoru KOMACHI <usata****@sodan*****> wrote:

> あともう一つ気になるのですが、SKK-JISYO で lisp 式を使ったものも変換候
> 補に出てくるのですが、これどうにかなりませんでしょうか? ';' が入った
> SKK-JISYO.L や 2ch.t からコンバートした SKK-JISYO.2ch では顔文字なんか
> が concat を使って書かれていたりして、uim-skk で変換しようとすると 
> lisp 式がそのまま出てきてしまうので、あまり使い勝手がよろしくありませ
> ん。skkinput では SKK-JISYO 中の lisp 式は無視されるみたいですが、突然
> 変換すると lisp 式が出てくるよりは、annotation と同様に無視されたほう
> が違和感はありません。また、関係あるかどうか分かりませんが、'(' や ')'
> を含むエントリをuim-skk で登録しようとしても登録されないみたいです。

 候補をまるごと無視するというのは、小手先の改変では難しそうです。辞書か
ら候補を検索してくるのはskk-dic.cでやっているのですが、私はskk-dic.cは半
分程度しか理解できてないので、厳しそうです。とりあえず挑戦してみて、ダメ
なら後回しにしますね。

> 個人的にはそれほど処理が重いと感じたことはないのですが、skkinput なら
> できることが uim-skk ではできない、というのがいろいろとあるので、現段
> 階では skkinput を使うにも一理あるなと思います。Mozilla と組み合わせて
> 使うのであれば、uim-skk のもっさり感よりは Mozilla のもっさり感のほう
> がはるかに気になる、ということもあるかも分かりませんが……。
> 
> そういうわけで、「徳永さんには何度か伝えたことがあるので耳にタコができ
> ているかもしれませんが、4. の『変換候補の選択にA〜Lを使わせろ』に一票
> 入れておきます。候補が70 個あるときなんかはスペースで次ページ、選択は 
> A-L となっていると操作も速いですし、SKK ならこうだろうというつもりで使
> っているのにuim-skk だとスペースで次候補(次ページに飛ぶ手段も、一覧の
> 候補をキー1つで選択する手段もない)なのは使いにくいです。

 候補の次ページ移動はたしかに欲しいですね。私も候補が20個以上出てきたと
きには候補選択がめんどくさいです。

 しかし、この機能を実装するためにはいくつかの壁があります。

 まず、現在のuimには候補の表示に関して一ページ二ページという概念がそも
そも存在しないので、scheme側からここらへんを操作するのは現在の仕様では不
可能です。でも、候補の表示に関して特に仮定を置かないのはuimの設計の良い
ところだと思うので、この利点は崩したくないのです。
 ならばimmoduleやXIM Serverの方で入力を処理すればいいのかというと、そう
いうわけにもいきません。scheme側で扱っておかないと、キーバインドのカスタ
マイズがやりにくくなってしまいます。
 結局、のぞましい解は、なんらかの新しいAPIを追加して、候補ウィンドウな
どをもっと柔軟にscheme側から扱えるようにする事だとおもうのですが、これは
気をつけてAPIを追加しないと不自然なデータ構造になってしまったり、不自然
なAPIになってしまったりする恐れがあります。
 そして、どうせ慎重に設計するなら同時に候補ウィンドウの概念自体をもうち
ょっと抽象化したり、候補ウィンドウの機能を拡張したりしたいなぁ、などと考
えています。
 こんな事をグダグダと考えてるからなかなか実装が進まないのですが、開発が
ちょっと遅れることになっても、あとあとの事を考えると、できるだけ物事を抽象
化しておくのは、決して損にはならないと思っています。



-- 
徳永拓之



Anthy-dev メーリングリストの案内
Zurück zum Archiv-Index