日記みたいな何か

久しぶりにH320つけようと思ったらバッテリあがってました(´・ω・｀)．rockbox，takkaさんのところから新しいの落としてきて入れたらなんかずいぶん軽くなったような．

これはいいかも．変換候補，かなり安定した感じが．

本日は 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)

他にどんな"不思議な点"があるのだろうか・・・．

mltermとかEmacsで文字のゴミが残る問題ですが，どうもuim-toolbar-gtkと同じ行に表示されている部分にゴミが出ている模様．いつもuim-toolbar-gtkを画面の一番下に置いていたために，縦いっぱいに広げたウィンドウの一番下の行だけが乱れていたようで，uim-toolbar-gtkを上の方に動かしたら，上の方が乱れました．他にもFirefoxの出すtooltipと同じラインの文字も崩れたりするんで，Gtkの何かが問題を起こしてたりするのかなぁ．

新しくいじってるやつ，XEmacsだと変換候補をインラインで表示した際に色が抜けてしまうことが発覚．変換候補と同じ行に font-lock-comment-faceやfont-lock-string-face，font-lock-keyword-face あたりがついた文字列があると，変換候補が出た瞬間に色が抜け落ちます．が，何故か font-lock-reference-face だけは色が残る模様．なんじゃこりゃ．

試しに after-change-functions を nil にして buffer-substring で切り出してみると，font-lock-reference-face のところは切り出した文字列にもちゃんと色がつくのに，それ以外の場合だと，切り出した文字列に色がついてくれません．うーん．

get-text-propertyで face を引っ張り出してみると，色が切り出されるところは「(font-lock-reference-face)」という風にリストが返ってきています．一方，色が抜けちゃうところは「font-lock-comment-face」とか「font-lock-string-face」みたいにface名(?)が返ってきます．この辺が鍵を握ってるのか？

とりあえず↓みたいなの書いて，変換候補が重なるところのfaceを全部リストに直すようにしてみたら何と色が抜けなくなりました．いいのかこんなんで・・・．ていうか，こんなことばっかやってるからぐちゃぐちゃになるんだよなぁ．

(defun uim-overwrite-font-face (start end)
  (let ((facelist '()) tail face)
    (catch 'face-loop
      (while t
        (setq tail
              (next-single-property-change start 'face (current-buffer) end))
        (if (setq face (get-text-property start 'face))
            (if (atom face)
                (put-text-property start tail 'face 
                                   (cons face nil))))
        (setq start tail)
        (if (= start end)
            (throw 'face-loop t))))
    )
  )

しかし，ほんと，XEmacsでuim.el使ってる人ってどんくらいいるんでしょね・・・．

一応5ボス倒せそうなところまで行けました．でも相変わらず何でもないところで死んだりするのが悲しい・・・．1周はまだ夢のまた夢・・・．

ビューティフル！ PS3買うこと決定ですなー．

海ステージばかりを練習．うーん，ボスが苦しい・・・．

今日のセガダイレクトの表示は今までに無いくらい重い・・・T60にしてから初めてかも．

いきなりC-g押すとfont-lockがおかしくなる問題ですが，あっさり直りました．キー処理まわりは地獄だ．よくこんなんで動いてるな・・・．

もう出てるぅ．

なんか疲れて元気なくなりかけてたんですが，音楽聴いてるうちに落ち着きました．あー，M3は29日なんだよねー．肉の日．

ほんとかよ(笑)．感激した．でもあんまりノシノシやってると急に叩きの流れに入りそうで怖い(;´д`)．まあ，突っ込まれどころいっぱいあるんでしょうがない気もしますが．

ちなみにソース見てないので確証は持てませんが，インライン変換できなくなる(？)ってことはオーバレイ使われちゃってるのが原因ですかねー．オーバレイ，やっぱどうにもならんかなぁ・・・．