Ikumi Keita
ikumi****@rever*****
2003年 10月 1日 (水) 23:44:30 JST
井汲です。 > Canna 3.7のβ版を作りました。テストに御協力お願いします。 【1】make canna の途中で、 cc -o cannastat -L/usr/local/canna3.7/lib cannastat.o -L../../lib/canna -lcanna -L../../lib/RKindep -lRKindep -Wl,-rpath,/usr/X11R6/lib cannastat.o: In function `main': cannastat.o(.text+0x202): undefined reference to `RkcSendWRequest' cannastat.o(.text+0x22f): undefined reference to `RkcRecvWReply' *** Error code 1 となって止まってしまいました。しばらく 3.7 系に触れる時間がなくて、 /usr/local/canna3.7/lib に少し古いライブラリが残っていたのが原因のようで す。 Canna.conf で LDOPTIONS = $(CDEBUGFLAGS) $(CCOPTIONS) $(LOCAL_LDFLAGS) -L$(libCannaDir) となっていた所を LDOPTIONS = $(CDEBUGFLAGS) $(CCOPTIONS) $(LOCAL_LDFLAGS) と変更した上で make canna してみるとうまくいきました。 【2】renbun-continue について。 > ・(setq chikuji-continue nil)としておかないと(setq renbun-continue nil) > が効かない問題を修正しました。renbun-continueのデフォルト値はnilでしたが、 > tであるかのように動作していたため、この修正に伴いrenbun-continueのデフォルト > 値をtに改めました。 とありますが、renbun-continue のデフォルトは逆の方がいいと思います。 Canna 3.2 の頃は renbun-continue=nil 相当の動作でした（で、私もその方 が使いやすいと感じます）。3.5beta で動作が変わったのですが、Canna ML の 過去ログを見ると、今さんは「デフォルトを変えるつもりはなかった。変わって しまったのはミス」と認識されています。 関連部分の抜粋を以下につけます。 井汲 景太 [Canna 4575] 今さん > さて、実は狩野さんのおっしゃる通り C-k、C-d でも C-g で戻れ > るようにする時に、単候補状態での文字入力についてもからんでく > るのでこのあたりのソースも修正しました。そのときに、単候補状 > 態から文字入力を行う時に、前の部分を確定するかしないかを判定 > しながら進まなければならないのですが、確定するかしないかのた > めの変数が chikuji-continue と renbun-continue の2つが用意さ > れていてちょっと混乱が生じていました。と言うのは次の入力が逐 > 次用の入力か、そうじゃないかは結構シビアな部分があるんです。 > そもそも前の部分を確定させるかどうかは逐次かどうか関係無しに > できるべきかな、と思い今回は chikuji-continue あるいは > renbun-continue のいずれかが t であれば前の部分を確定させな > いようにしてあります。そして、β2では chikuji-continue のデ > フォルトが t だったので狩野さんのご指摘の問題が生じていたの > でした。 > この部分、chikuji-continue のデフォルトを nil に振る方向に持っ > て行きたいのですがいかがでしょうか？ [Canna 4579] 狩野さん >> そもそも前の部分を確定させるかどうかは逐次かどうか関係無しに >> できるべきかな、と思い今回は chikuji-continue あるいは >> renbun-continue のいずれかが t であれば前の部分を確定させな >> いようにしてあります。そして、β2では chikuji-continue のデ >> フォルトが t だったので狩野さんのご指摘の問題が生じていたの >> でした。 > 逐次の時と連文節変換の時とで前の部分の確定不確定は別々に > 制御できた方がいいと思います。使いもしない逐次変換の変数の > デフォルト値が書き換えられただけで、連文節変換の振舞いが > 変わるのって、あまり気持ち良くありません。 > それに、連文節変換だと「入力しても以前の入力が確定しない」と > いうのは相当違和感がありますが、逐次変換ならそれはそれで > 筋が通った動作のようにも感じます。「別々に制御したい」と > 思う人がいても不思議はありません >> この部分、chikuji-continue のデフォルトを nil に振る方向に持っ >> て行きたいのですがいかがでしょうか？ > renbun-continue, chikuji-continue の二つの変数を置くので > あれば、それぞれ個別に制御できるのが自然な仕様だと思います。 [Canna 4668] 今さん >> それに、連文節変換だと「入力しても以前の入力が確定しない」と >> いうのは相当違和感がありますが、 > これですが、ず〜っと以前(Version 1.x のころ)からある人に強く > 勧められていた機能で、Version 3.2 あたりで入った機能なんです。 > 実は最近は自分の環境は連文節変換でも前の方が確定しないように > なっています。確かにちょっと気持悪いですね。undo との絡みが > 特に。 > ただ、Emacs 以外の、確定 undo をちゃんとサポートしないような > 環境ではちょっとだけ便利です。確定したような気持でも実はそち > らの文節に戻れますから。 >> renbun-continue, chikuji-continue の二つの変数を置くので >> あれば、それぞれ個別に制御できるのが自然な仕様だと思います。 > う〜ん、変数を統合しようかしら。あくまで統合の方向に持って行 > こうとする私。 [Canna 4677] 狩野さん > それに、連文節変換だと「入力しても以前の入力が確定しない」と > いうのは相当違和感がありますが、 >> これですが、ず〜っと以前(Version 1.x のころ)からある人に強く >> 勧められていた機能で、Version 3.2 あたりで入った機能なんです。 > 未確定文字列が入っている状態で入力すると以前の部分を確定する > 仮名漢字変換の方が多数ですよね？ 操作性を制御できる選択肢が > 増えるのは良い事だと思いますが、こういう基本的な操作体系の振舞い > のデフォルトを知らぬ間に変えられていると、ちょっとぎょっとします。 > キーバインドのような表層的な部分は、変わっても問題ないんですが。 >> 実は最近は自分の環境は連文節変換でも前の方が確定しないように >> なっています。確かにちょっと気持悪いですね。undo との絡みが >> 特に。 > 最初の undo では、最近に入力した部分だけが仮名に戻り、次の undo > で全部もとに戻るのならそれほど気持ち悪さは無いかもしれません。 > ＃それでも、(setq renbun-continue t) しようとは思いませんけど:-)。 >>> renbun-continue, chikuji-continue の二つの変数を置くので >>> あれば、それぞれ個別に制御できるのが自然な仕様だと思います。 >> う〜ん、変数を統合しようかしら。あくまで統合の方向に持って行 >> こうとする私。 > [Canna 4457] で今さんに > |で、良くみると同じようなものがたくさんあるんです。これは > |version 1.2 の時にモードが増えるたびに機能が爆発的に増えたの > |に嫌気がさしたのでこのような整理統合をしたように記憶していま > |す。ついでにモードの統合もして、リアルモードとイマジナリモー > |ドに分類されたりしています。 > とうかがって、機能の数を増やさないように配慮していることを理解 > しましたが、この考えからすると、renbun-continue, chikuji-continue > の二つの変数は統合した方が良いように思います。連文節変換モードと > 逐次変換モードは排他的ですから。 > 連文節変換と逐次変換をしょっちゅう切り替える人は普通いないでしょう > （評価目的でIMEを使う太田さんぐらいだと思います :-)）けど、中には > 切り替えて使うんであれば、それぞれで「入力が確定をもたらすか」を > 個別に設定したい人だっているでしょう。私がもし連文節変換を使うと > したら、chikuji-continue が t である方が好ましいと思うかも知れません。 > で、連文節と逐次の両方を切り替えて、変数一個で両方の振舞いを独立に > 記述しようと思ったら、切り替え操作と一緒に変数を書き換えるしか > ありませんね。 > (global-set-key "\C-\\" '(renbun-mode (setq chikuji-continue nil))) > (global-set-key "\C-o" '(chikuji-mode (setq chikuji-continue t))) > とか（setq なら引数の個数が分かってるから括弧は要りませんけど、 > 読みやすさのために付けてあります）。 > さらに、extend-mode で出したメニューの振舞いも同時に切り替えることが > 簡単に出来れば嬉しいでしょうね。メニューの内容を一部だけ書き換えるなら > defmenu で全部書き換えないで済ませたい。とすると、関数かマクロで名前を > 付けられるようにした方が便利だし…と、ほとんど「Lisp で書きたい！」と > 言っているのと同じになってきましたね。 > 「こういうのを出来るようにしてくれ」とは言いません。だって、きっと > 使いませんから（他の所で使うかも知れないけど）。なのに、このあたりの > 話をするようになったのは、太田さんや藤枝さんに洗脳された結果でしょう:-)。 > 将来、Canna 4 か 5 の時に、この辺の操作性の設計を考え直す時には、 > こういう話はいろいろと出て来るんじゃないでしょうか。 > さて、話は「今してほしい事」に戻りますが、renbun-continue と > chikuji-continue を統合するとき、continue という名前だけはやめて > ほしいと思います(^_^;)。 > input-makes-kakutei と言うような名前が良いんじゃないでしょうか。 > t と nil が逆になってしまいますが、βのうちなら大丈夫でしょう。 [Canna 4683] 今さん > 未確定文字列が入っている状態で入力すると以前の部分を確定する > 仮名漢字変換の方が多数ですよね？ 操作性を制御できる選択肢が > 増えるのは良い事だと思いますが、こういう基本的な操作体系の振舞い > のデフォルトを知らぬ間に変えられていると、ちょっとぎょっとします。 > ごめんなさい。デフォルトを変える気は無かったのです。変わって > しまったのは単にミスなんですよ。本当にごめんなさい。 > ＃そもそも私、デフォルトを変える時はアナウンスをするようにし > ＃ています。 >> さらに、extend-mode で出したメニューの振舞いも同時に切り替えることが >> 簡単に出来れば嬉しいでしょうね。メニューの内容を一部だけ書き換えるなら >> defmenu で全部書き換えないで済ませたい。とすると、関数かマクロで名前を >> 付けられるようにした方が便利だし…と、ほとんど「Lisp で書きたい！」と >> 言っているのと同じになってきましたね。 > あと、Canna を台湾対応に現地法人が変更した時の話ですが、キー > プレスでマウントする辞書を変更したいなんて言う希望もありまし > た。 > かな漢字変換動作記述言語って本当にいるのかも知れませんね。 >> 「こういうのを出来るようにしてくれ」とは言いません。だって、きっと >> 使いませんから（他の所で使うかも知れないけど）。なのに、このあたりの >> 話をするようになったのは、太田さんや藤枝さんに洗脳された結果でしょう:-)。 > そうですねぇ。 >> さて、話は「今してほしい事」に戻りますが、renbun-continue と >> chikuji-continue を統合するとき、continue という名前だけはやめて >> ほしいと思います(^_^;)。 > なるほど。 >> input-makes-kakutei と言うような名前が良いんじゃないでしょうか。 >> t と nil が逆になってしまいますが、βのうちなら大丈夫でしょう。 > 考えます。
