2007年4月22日の日記の1番目の記事へのコメント
■uim.el
本日は pc-selection-mode 問題を.pc-selection-mode が有効な際に,uim.elが有効になってると,シフト+矢印で領域を選択した後,BSとか押しても1文字しか消えてくれないという現象が発生します (本来は選択した領域がまるごと消える).
中で何やっとんじゃとdelsel.elを見てみると,事前に delete-backward-char とか self-insert-command とかに put で delete-selection なるプロパティを設定しておいて,pre-command-hook を使ってコマンド実行時に割り込んで,get で this-command の delete-selection プロパティを見て選択領域をどうするか決めてました.なんてわかりやすい.
で,何でちゃんと動かないかというと,uim.elが有効になってると 何を押しても uim-process-input がコマンドとして処理されちゃうため,どのキーが押されても pre-command-hook の中では this-command は常に uim-process-input になっちゃうんですねぇ.さて,どうしたものか・・・.
uim.el では,uimがスルーしたキーバインドについて,毎回キーバインドに対応するコマンドを調べて command-execute したりするわけなんですが,その際,command-executeする直前に pre-command-hook を run-hook すれば・・・この問題に関してはいいかもしれないですけど,1回のコマンドにつき2回 pre-command-hookが呼ばれるのは他にも影響がありそうでちょっと怖い.うーん.でも一応動く.うーん.
あるいは,uim.elの初期化後に,BSやC-h,Del といったキーの uim-process-input へのバインドを解除しちゃうってのもありですな.現状,uimは,プリエディットや変換候補が表示されていない状態でも,可能な限りキー入力に割り込んで uim 側に「このキー入力は処理するかどうか」を問い合わせるようになってます.が,実際のところ,Anthyのひらがな - カタカナ 切り替えを BS に割り当てるような変態さんはまずいないでしょうから,この辺のキーはプリエディットや変換候補が表示されるまで無視してもよかったりします(現状,何を無視すべきで何を拾うべきかの境界が曖昧なので全部拾ってる感じです).というわけで,.emacsとかに↓のように書いて uim-mode-map にどんどん穴を空けていけば,今の uim.el でも普通のエディタっぽい選択領域の一括削除やペーストによる上書きが可能になります.
(define-key uim-mode-map [25] nil) (define-key uim-mode-map [8] nil) (define-key uim-mode-map [4] nil)
が,ただし,「a」とか「b」みたいな,self-insert-command にバインドされてるキーにこれをやるわけにはいかないので,"領域を選択した上で「a」を押すと,選択したところが一気に消えて,代わりに「a」という文字が挿入される"という動作には対応できません (´・ω・`)
というわけで,やっぱ前者の pre-command-hook を中でもう1回呼ぶ方式がいいのかなぁ,という感じです.
あ,あと,XEmacsで使ってる人いるのかっつー話ですが,ググったら使いかけてやめたと思われる方の日記を発見しました.XEmacsって,デフォルトでシフト矢印で領域選択できるのか・・・.きちんとテストしてませんが,ひとまず以下のようなのを.xemacs/init.elとかに書き足すことで uim を読み込んだ後に設定されるようにしておくと解決しそうです.
(define-key uim-mode-map [(shift up)] 'previous-line) (define-key uim-mode-map [(shift down)] 'next-line) (define-key uim-mode-map [(shift right)] 'forward-char-command) (define-key uim-mode-map [(shift left)] 'backward-char-command)
他にどんな"不思議な点"があるのだろうか・・・.
2007年4月22日の日記の1番目の記事へのコメント
[コメントを書く]