YamaKen
yamak****@bp*****
2005年 2月 25日 (金) 12:55:40 JST
At Fri, 25 Feb 2005 05:01:00 +0900, komat****@taiya***** wrote: > どうもありがとうございます。 doc/COMPATIBILITY も配布アーカイブの中に > 加えておいていただけないでしょうか。 0.4.6beta2リリース後に別の方の指摘で修正済なので、次のリリースに は含まれるはずです。長い間気付かずご不便をおかけしました。 > prime.scm では、再帰編集を可能にするために、複数の context をネスト > させて使っています。 現在のtrunkにはそのようなコードは見当たらないんですが、小松さん の手元でそのように変更しているという話でしょうか。 > しかし、prime-context-new 内で > (prime-context-set-widgets! context prime-widgets) を複数回実行すると > アプリケーションごとエラーで落ちてしまい、対応が必要でした。 > 下のレイヤーで、なにかしらのエラー処理を加えてくださるとうれしいです。 実際のコードがどうなっているかわからないので想像で書きます。私は uim-primeの開発にはほとんどタッチしていないので的外れな事を書い ているかもしれません。 (prime-context-set-widgets! context prime-widgets)自体はエラーを 起こす事は無いはずなので、uim-primeで使われているmode-handlerと prop-activate-handlerがコンテキストの再帰に対応していない事が原 因じゃないかと思います。 register-imで登録されている以下の2つのハンドラは、コンテキストが create-context経由で生成されている事を前提に動作します。 context-mode-handler context-prop-activate-handler create-context内ではcontext-widgetsに含まれるシンボルをオブジェ クトに置換しているので、それを行わずにcontext-newで生成されたコ ンテキストに対して呼ばれるとおかしな事になるはずです。 以下の2つの独立した対応が考えられますが、 ・動作の正しさはともかく、エラーで落ちるのを回避する ・mode-handlerとprop-activate-handlerを再帰に対応させる 前者は非正規なコンテキストに対するエラーチェック強化という形で対 応できると思います。 後者は今のところprime.scm内で責任を持って専用のmode-handlerと prop-activate-handlerを作ってもらうしかないんじゃないかと思いま す。 私もskk-anthyといったIMを実現したいのでコンテキストのネストは欲 しいと思ってますが、0.6でcomposer frameworkという仕組みを導入し て対応するつもりでした。im-clear-preedit等ネストしたコンテキスト の頭越しにグローバルに作用するインタフェイスが多いので、現在の uimの仕組みではネストは難しいと思っていました。 ------------------------------- ヤマケン yamak****@bp*****
