Takashi Nakamoto
blued****@bpost*****
2006年 7月 10日 (月) 17:04:13 JST
中本です。 On Mon, 10 Jul 2006 16:04:10 +0900 Takuro Ashie <ashie****@homa*****> wrote: > > けれども、再変換するだけならば別に SurroundingText はいらないのでは > > ないかと思い、添付のパッチを作ってみました。説明がめんどうなのでこの > > パッチが何をするのかの説明は省きますが、一応Gtk+以外のアプリケーショ > > ンでも再変換ができるようになると思います。 > > > > ただし、このパッチは > > * X SelectionのPRIMARYに再変換したい文字列が格納されている > > * 文字列をcommitすれば、再変換したい文字列にcommitした文字列が上書 > > きされる > > ことを前提としています。 > > 大抵はこれでうまくいきますし、むしろsurrounding textを使う方法では前後 > に同じ文字列があると誤動作するので、こっちのほうが良い場合が多いとは思 > います。 この誤動作をする条件がよく分からないです。 ちょっと興味があるので、その条件を教えていただけますか？ > > ので、このパッチがうまく動作します。しかし、Emacsでは文字列を選択し > > ている間になにか文字を入力しても、選択中の文字列に入力した文字列が上 > > 書きされないため、期待しない動作をしますが、それはEmacsがそういう実 > > 装をしているので仕方ありません。 > > アプリケーション側がそういう実装であることを期待してしまうことになり、 > 動作が不確実なのがどうかな、ということでsurrounding textを使う方法を選 > んだわけですが、surrounding textも上述のように不確実なので、どうせどち > らも ad-hocな解であるならば、より多くのアプリケーションでの動作が期待 > できる中本さんのパッチの方が良いのかもしれません。 私のパッチでは、surrounding textが使えればそれを使い、使えなければ XSelection のみをつかって再変換をするように変更してます。surrounding textを使った方法がadhocな解であるのであれば、私のパッチはad-hocな解を2 つ用意しておき、場合によってより最適な ad-hoc を選ぶようにした、という 感じです。 > というわけで、取り込む方向で考えたいと思います。 ありがとうございます。 > もちろん、より確実に再変換を実装するためには、ちゃんとしたAPIとアプリ > ケーション側の対応が必要です。アプリケーション側で比較的労力をかけずに > 済む方法は、選択範囲文字列を取得するAPIを追加することかなと思っていま > す。 これは難しいですね。 大抵の場合は、X Selectionから取ってくればいいので、特にそういったAPIは 必要ないのでは無いでしょうか？ -- 中本 崇志 ( Takashi Nakamoto ) E-Mail : blued****@bpost*****, blued****@openo***** Homepage: http://bd.tank.jp/ blog : http://bd.tank.jp/diary
