Takuro Ashie
ashie****@homa*****
2006年 7月 10日 (月) 16:04:10 JST
足永です。 On Mon, 10 Jul 2006 00:37:36 +0900 Takashi Nakamoto <blued****@bpost*****> wrote: > さて、本題ですが、OpenOffice.org(on Gnome)とscim-anthyの組合せで再変換が > できません。原因追及のために先週scim、scim-anthy、OpenOffice.orgのコー > ドと睨めっこしてました。原因は OpenOffice.orgではGtkIMContextの > gtk_im_context_get_surrounding()が常に falseを返すようになっているからで > した(多分)。これについては、そのうち修正しようと思います。 すばらしい。期待してます:) > けれども、再変換するだけならば別に SurroundingText はいらないのではない > かと思い、添付のパッチを作ってみました。説明がめんどうなのでこのパッチが > 何をするのかの説明は省きますが、一応Gtk+以外のアプリケーションでも再変換 > ができるようになると思います。 > > ただし、このパッチは > * X SelectionのPRIMARYに再変換したい文字列が格納されている > * 文字列をcommitすれば、再変換したい文字列にcommitした文字列が上書きさ > れる > ことを前提としています。 大抵はこれでうまくいきますし、むしろsurrounding textを使う方法では前後に 同じ文字列があると誤動作するので、こっちのほうが良い場合が多いとは思いま す。 > ので、このパッチがうまく動作します。しかし、Emacsでは文字列を選択してい > る間になにか文字を入力しても、選択中の文字列に入力した文字列が上書きされ > ないため、期待しない動作をしますが、それはEmacsがそういう実装をしている > ので仕方ありません。 アプリケーション側がそういう実装であることを期待してしまうことになり、動 作が不確実なのがどうかな、ということでsurrounding textを使う方法を選んだ わけですが、surrounding textも上述のように不確実なので、どうせどちらも ad-hocな解であるならば、より多くのアプリケーションでの動作が期待できる中 本さんのパッチの方が良いのかもしれません。 というわけで、取り込む方向で考えたいと思います。 もちろん、より確実に再変換を実装するためには、ちゃんとしたAPIとアプリ ケーション側の対応が必要です。アプリケーション側で比較的労力をかけずに済 む方法は、選択範囲文字列を取得するAPIを追加することかなと思っています。
