2008年4月10日の日記の1番目の記事へのコメント
■uim.elの変換候補
今まで uim.el では超狭いウィンドウに変換候補をインライン表示しようとした場合,はみ出して表示させてました.つまり,変換候補の一部が表示されない状態.そんなアホみたいに狭いウィンドウで変換する奴なんかいねーだろと思っていたので・・・が,何とどうにかしろという要望がw
というわけで,まず,インライン変換候補表示するにはバッファの行数が足りなくてはみ出てしまうような場合は,強制的にインライン変換候補表示を無効化するようにしてみました.これは楽勝.
次に,エコー領域に表示する変換候補を整形します.今までは,Emacs21以上の場合,Emacsのエコー領域のリサイズ機能に任せて何も考えずに変換候補を横に並べたものをエコー領域に出力していたんですが,ウィンドウの高さが極端に小さい場合,エコー領域のリサイズにも限界が生じることから,これだと場合によっては現在選択中の変換候補が見えない事態が生じてしまいよろしくありません.
そんなわけで,『変換候補をエコー領域に表示した場合に何行消費するかをこっそり確かめた上で,実際に表示してみて全部表示しきれてないようだったら切り詰める』 という処理を追加してみました.
まず,こっそり確かめるために,新たに隠しバッファを追加して,ここに変換候補を書き込んだ上で, minibuffer-window で取れるウィンドウにセットしてみて,高さを見積ります.で,次に実際に message でエコー領域に表示させて,エコー領域の高さがさっき見積もった高さと同じだったらそのまま何もせず,小さかったら全部表示できていないってことなので,切り詰め処理を行って再表示する・・・と.
次に,切り詰め処理の方ですが,こっちはエコー領域が勝手にでかくなってくれない Emacs20・XEmacs 向けの変換候補を1行に切り詰める仕組みをちょっといじればいいのですぐできるはず・・・だったんですがここではまりました.自分で書いたはずの処理が読み返してもさっぱりで,どこを「ちょっといじればいい」のかが全然わからん (;´Д`).変数の名前は適当だし,謎の定数の足し引きをしてたりするし,何でこれでうまく動いているんだろうって感じです・・・.上の方から読み返して変数名を付け替えたりしてどうにか乗りきれましたが,できることならもう触りたくないですなぁ,この辺・・・.
そんなわけで,現状↓な感じになってます.
[コメントを書く]
2008年4月10日の日記の1番目の記事へのコメント
アホな要望でJ( '-`)しゴメンネ
なるほど,rieceでは確かにちっこいバッファが作られますね.
そういえば,以前,uim.el は rieceと組み合わせるとちゃんと動かない
という報告を頂いたことがあったんですが,その辺は大丈夫ですかねぃ
#自分の環境だと再現できなかったもんで