日記みたいな何か

UI-70さんの「幻視の夜」が委託始まったそうなんでひさびさにとらのあな行って買ってきました．うほ，たまらん．なんかギターの音が声みたいな．あとメロンよったら棚のはじっこに見慣れぬCDを発見．手に取ってみてみるとバウハウスさんの「Le Cercueil Du Reve」なるクロノトリガーアレンジの模様．誰がやってんのかなーと裏見た瞬間購入決定(;´Д｀)ハァハァ．後で調べたら，結構前のCDみたいっすね．というか，バウハウスさんのWeb，IE以外だと見えませんな・・・．サーバがContent-TypeをText/Plainで返してきてるのか・・・．次のIEではきちんと表示されなくなるのかなぁ．

で，話変わりまして，こっちはよみさんからの情報なんですが，夜空的輝煌なるサークル(?)が「蒼月的碎片 〜 Thousands of Sapphire Crescent」なんていうCDを出す模様．中見ると東方とかクロノとか色々入ってて試聴した感じよさげです．が，このCD，なんと「fancy frontier」なる台湾の即売会で頒布なんすよねー(台湾のサークルだから当り前ですが(^^;)．去年，さざなみ壊変さんのところにリポートが出ててへーとか日記に書いた気がしますが，あのイベントです．いやー，こりゃ無理だな(^^;．

ちなみに，こちらのサークルの方の日記を見ると，

修羅場持續中………

とかあったりして，やっぱどこも直前は同じなのかという感じです(笑)．というか，やっぱUnicodeって偉大だなぁ．向こうの方はどうやって日本語入力してるんでしょう・・・．普通にローマ字変換なのかな？

ちゃんとuim.elから使えるのか実験してみようと思い，Canna-3.7p1とSCIM-1.2.3を入れてみたんですが・・・残念ながらどっちもうまく動いてくれませんでした(´・ω・｀)．Cannaの方は，uim-pref-gtkでサーバのアドレス指定したり，デフォルトのIMに設定できたりするんですが，いざ各種アプリから使おうとすると選択候補に出てきません．んー，libcannaのビルドに失敗しているのか・・・？

SCIMの方も，scim-m17nとかがuim-pref-gtkから見えるんですが，やっぱりCannaと同じような感じで使用することができないっす．んー．しかも--with-scimでビルドしているとuim-pref-gtkを終了させた時にセグるし・・・．さて，どっから問題を探ればいいんだろうか・・・．

あああ，r977だとprimeがちゃんと動かないし・・・ってmltermからだとちゃんと使えるってことはuim-agentが悪いのか＿|‾|○．0.0.3は遠い・・・．

表さんからleimへの対応のリクエスト(?)がありました．なるほど，マイナーモードだけだと他のIMとの共存が面倒な場合があるのね．内部実装にばかり頭が行っていて，運用面でどうかという発想が欠けてました．というか，機能そのものに対する希望が出たのは初めてな予感．

まあ，そんなわけで，今度はまじめに対応を検討してみました．なるほど，上からどう見えるかが重要だから，内側に関してはleimが活性化したらマイナーモードをONにして，不活性化したらOFFにするだけ十分なのか．問題は，上にどう見せるかですね．

(おそらく)通常，IMをleimに対応させる場合，register-input-methodなる関数を呼んでやる必要があります．この関数，1個目の引数に「japanese-anthy」とか「japanese-prime」みたいなIMの名前を取り，2個目の引数に対応する言語(?)を取って，呼ぶと各言語に対してIMが関連づけられるみたいな感じになります．で，ここで(；´-`).。ｏＯ(そういえばUimは何語のIMなんだ？) という問題が．

おんなじUimでも名前を変えて「Japanese」には「japanese-uim」，「Korean」には「korean-uim」，「Chinese-GB」には・・・みたいにやろうか，それともせっかく多言語対応なんだから「multilingual-uim」という名前で各種言語に登録した方がいいのか(後でわかったけど言語間で名前がかぶっちゃいけないのでこれは実は使えない)・・・とかぼやいてたらtkngさんから「japanese-anthy-uimみたいな感じで複数のIMとして登録しては？」との提案が・・・Σ(゜д゜lll)

つまり，同じUimでも，後ろでうごいてるエンジンによって名前を「japanese-anthy-uim」とか「japanese-skk-uim」とか切替えるという感じです．なるほど，その手があったかーという感じであり，何かせっかくUimなのにもったいねーなという感じでもあるのですが，上から見る分にはこれが一番わかりやすそうなので，これで実装してみることにしました．

まあ，そんなんで，ひとまず対応できました．他言語のIMに切替える場合は，(set-language-environment 'Chinese-GB)とやって言語を切替えて，(set-input-method "chinese-gb-py-uim")とかやってUimの下のIMを切替えるみたいな感じになりました．「japanese-anthy-uim」な感じの部分は，いったんuim-agentを呼んで，使えるIMの全リストをごっそり持ってきて，そのうちEmacsが対応している言語についてのみ登録するみたいな具合でやってます．leimの初期化の段階でuim-agentとお話をしなければならないので，結局最初からuim.el本体を読み込む必要があり，全然スマートじゃなかったりします．autoloadとか使ってみたいもんですが・・・．

・・・あ，0.0.3ですが，もうちっとお待ちを・・・．

最近ついに50人を突破したmixiのgaimコミュニティですが，何かYahooで「〜」が文字化けするという話題が出てたので，実験してみたところ，Win版gaimだと確かにおかしくなることが判明．ソース見て，ちょっとデバッグメッセージ出してみたらすぐ原因わかったんで対処してみました．yazさんパッチの関数呼んでるだけですが・・・．ひとまずWindows版に関しては自分の環境ではこれでよさそうです．Yahooって，回りで使ってる人ほとんどいないからよくわかんないんですよね・・・．

塊魂買いに行ったt○c氏から横浜ヨドバシに高橋名人っぽい人がいるぞとの報告が入ったので，すかさずmixiで見てみると，確かに日記に「横浜のヨドバシにいる」と書いてあります．ていうかイベント会場からも書いているのか(^^;．すごいよ，名人！

uim.elがEmacs-20.7入れて動くか試してみました．特に何も直したりすることなく，あっさり動いてくれました．あー，font-lock有効にしてると確定のたびに一瞬待たされるようになっちゃうのがちょっとまずいかも．どうしよう・・・．

ついでにuim.elがどこまで古いのでも動くのか試してみたくなりMule-2.3を入れてみることに．が，手元のT42の環境だとビルドの途中でできるバイナリがセグって落ちるため，ビルドが完了しません．何かgamlloc云々でこけてます．試しに別の環境でビルドしてみたところ，そっちでは無事通ったので，そっちで作ったのをコピーして使うことに．

で，早速uim.elをロードしてみたところ，unlessとwhenがないと言われていきなり失敗．そんな，Emacs19だと使えないんですか・・・？ついでにsave-current-bufferもダメだそうで．まあ，この辺はちょっと書き直すだけでどうにかなりそうですが，致命的なことにソースgrepしてみた感じだと，truncate-string-to-widthも使えないっぽいです．これがないと，変換候補のインライン表示できないよー(まあ裏を返せばインライン表示を切っておけばこの関数なくても平気ということなんですけど)．

と，まあこのあたりで虚しくなったので調べるのやめにしました．uim.elはEmacs-20.7.1以降/XEmacs-21.4.17以降をサポートということで・・・．しかし，いまだにMule使ってる人がいるってのが恐ろしい話です(知ってる範囲では一人だけど)．まあ，そんな人がuim使ってくれるわけねーか(´∀｀)'`,、'`,、．

やばいっす．変わらぬ面白さでした．午後はずっと転がしてました．右手の親指に水膨れができました．よく考えたら，本腰入れてゲームすんのすごいひさしぶりかも．最近，ワンゲームちょっとやって終わりなパターンが多かったし．

連日Emacsの話題ばかりですいません．誰に謝ってんだかよくわかりませんけど．で，Emacsの1行の幅なんですが，今までずっとwindow-widthの値を盲信してたんですけど，良く考えたらターミナルであげたときとか，21.xより古い奴とかは，一行にwindow-width入らないんでした．window-width文字目までいくと勝手に「\」が補われて折り返しが発生してしまいます．昔は当り前だったわけですが，21.xではXであげた場合，フリンジとかいう領域に折り返しマークが出るため，「\」は挿入されないんですよね．マジですっかり忘れてました．道理でXEmacsで1文字ずれるわけです．

XEmacsでuim.elの動きがおかしくなる理由のひとつに，truncate-string-to-widthの動きがGNU Emacsと違うというのがありました．GNU Emacsではちゃんと表示幅通りに刈り込んでくれるため，「あいうえお」を幅4で刈り込むと「あい」になるんですが，XEmacsだと，意味わからんことに律義に文字数分刈り込んでくれて「あいうえ」を返してきます．

何か対策ないのかとググってみたら，Mewの偉い人の発言を発見．

しかし、Emacs と XEmacs で動作が違うようなので、利用をあきらめます

・・・＿|‾|○．

さすがに代わりになるものを自前で用意するのはしんどいんで，GNU EmacsのをXEmacsで使いまわせないかと GNU Emacsのソースの中見てみたら，なんか普通にこの関数，international/mule-util.elなるファイルに普通にlispで書いてありました．ためしにその定義の部分をXEmacsで読み込んでみたら・・・お普通にXEmacsでも動くじゃん．

ということは，単にXEmacs側のtruncate-string-to-widthがおかしいってことか？grepして探してみると，何か定義が2箇所あります．一つは，mule-packages/lisp/mule-base/mule-util.elってファイルの中にあって，GNU Emacsのinternational/mule-util.elとまったく同じ．もう一つは，obsolete.elとかいうファイルにあって，substring使ってる超短い記述です．

#### This function is not compatible with FSF in some cases.

とか書いてあるし(;´Д`)．で，XEmacs普通に起動して(featurep 'obsolete)とかしてみると，tがかえってくるわけですよ．

というわけで，uim.elの中で(load "mule-util")してmule-util.elの方を読み込むようにしてやったところ，見事問題解決．ああ，やっとXEmacsでまともに動くようになった・・・．しかし，なぜ，obsoleteなんていうのを最初から読み込んでいるのか・・・．互換性のため？sumoの入れ方悪い？もう全然わかりません．

XEmacsに飽きたのでleim対応の方をちょこっといじってみました．Anthyのを参考に・・・って，これ，activateした後マイナーモードをONにしているだけなのか？prime-elの方も，どうも同じような雰囲気な気が・・・．うー，「Library of Emacs Input Method」というくらいだから，

• あらゆるキー入力を渡す関数を，指定したIM用の関数に渡してくれる
• IM用の関数が入力をスルーしてnilを返したら，本来のキーに割り当てられた処理を普通にEmacsがやってくれる

という感じで，手で書くとすげーめんどくさいような仕組が用意されているに違いない！と期待してたんですが，何かそれとは違うみたいですね・・・．（　´_ゝ`）フーン，translationにconversionねぇ・・・．ひとまず C-\ でuimがactivateするようになりましたが，意味なさそうなので消しちゃいました．誰かleimに対応することのうれしさ・素晴らしさをご存知の方，教えてくださいませ．

で，insert-in-front-hooksですが，ソース見返してみたら，使わないでもoverlay-endを見ればどうにかなりそうなことがわかったので，一ヶ所をのぞいて使わないようにしてみました．どうしてもだめなところは，とりあえずXEmacsだとオーバレイずれるけど我慢するってことで後回し．ここ直したら，無事XEmacsでもAnthyで入力できるようになりました．が，インラインで変換候補を表示すると驚く程ずれます．

ずれるところから少しずつ戻しながら追ってみたところ，(format "%-7s" 文字列) みたいにしてるところでずれが始まってることがわかりました．整形する文字列に全角文字が入っている場合，Emacsだと，画面に表示したときの文字幅が半角文字7文字分になるようにスペースを補ってくれるのに対し，XEmacsだと，単に文字数の合計が7文字になるように半角スペースを補ってくれます．なので文字列に「あ」を渡すと，Emacsではスペースが5個補われるのに対し，XEmacsでは半角スペースが6個補われちゃうと．

そんなわけで，整形にformat使うのやめて，string-widthの値から必要なスペースの幅計算してmake-stringでスペース並べるように書き直してやったところ，ようやくずれがなくなりました．ふぅー．しかしまだまだ不安定．この日記も途中までXEmacsで書いてたんですが，途中で変換候補出したら操作不能に陥ったし＿|‾|○．とりあえず，残ってるisert-in-front-hooksなんとかしないと・・・．