日記みたいな何か

確保したッ！

当初，カセットが認識されず，吹いても接点復活剤を塗っても全然ダメで超焦ったんですが，やや浅めに挿してみたところ無事に起動してくれました．深く挿すと認識されんとは・・・

いちいちクリップを使って配線しないとサウンドを出せないのは (´・ω・｀)ボンショリ (というか超不便) なので これを作ろうと思ったんですが，手元にケーブルの余りがありませんでした(´・ω・｀)．PCから引っこ抜くかと思ってPCを開けてみたら，装着すらしていなかったし ＿|‾|○．こんなパーツ，以前はガラクタ箱をあさればすぐに出てきたもんですが・・・今はガラクタ箱は遠くに・・・はぁ．ていうか確かにマニュアル無いのは不便だよなぁ．ディップスイッチとか全く意味わからんし．

ようやく6面をノーミスで抜けることに成功したぞ！ 何度も YouTube にあった動画 (x68k版だけど) を見返したかいがあったというものｗ．が，その後，7面で不用意にビッグコアに近づきすぎて最初のレーザーをモロに喰らって死亡 orz．ザブラッシュでどうにかそこそこ復活して8面までいけたものの，いつも通り最初の細いところで終了．はぁ．

一昨日あたりから，左耳のちょっと後ろの方 (骨ばってるところというのかな？) が時折ズキッと痛むことがあったんですが，昨日の夜あたりからかなり周期が短くなってしんどかったので昼まで寝てました．

おかげでだいぶ回復．まだたまにズキッときますが，頻度は相当減りました．寝れば治るってのはありがたい話ですｗ．そういえば去年の秋頃もこんなのあったなぁ．痛い場所は違ったけど，症状は似ていたような・・・．

昨日の続き．Emacs20で色々テストしてたら，インライン変換候補表示の方でおかしな動作を発見してしまいました (;´Д`)．同じく，バッファが極限までに狭い場合に発生する問題なわけなんですが，こちらも昨日のパターンと同じで，何この変数？何この定数？そして何この引き算？・・・みたいな．

バグを追ったり直したりしているうちに，変換候補消去時のスクロールがおかしい問題とかも気になり始めてしまい，こちらも色々修正．長いこと放置していた，変換候補を消した際のスクロールの挙動とか，多少は良くなったかも？ 試したい方はこちらをどうぞ．さっさと commit したいところですが，これがちと不安・・・．

コネクタ部分の接触が悪くてしょっちゅう色が抜けるデミロのコネクタ部分をバラしてみました．シールドを外す前に後ろから覗いてみたら，はんだ面との間に何かが入っている感じ．何だろこれ・・・と思ってたら，ポロッと落ちてきました．何と単なる厚紙でした (笑)．絶縁用ですかね．裏に「13/」とか手書きの文字が書いてあって，そこら辺の適当な厚紙を切っていれただけに見えます(笑)

シールドを外すと，中はこんな感じになってました．切れたりはしてないっぽいんですが，いかにもハンダ付け不良が起きてそうな雰囲気です．あとでここはつけ直しですねー．

で，本体側もあけてみました．はんだ面．そして部品面．コネクタの信号は，16本全部が本体まできちんと配線されているっぽいです．素晴らしい．映像出力のモードを切り替える SELECT1 と SELECT2 の信号はパターン上でつながっていて，両方OPENか両方GNDのどちらかしか選べないような構造になってました．ここをカットして，どっかにスイッチを増設してやれば，15kHzモードへの切り替えは簡単にできそうです．

あとは，どこにコネクタとスイッチを増設するかなんですが・・・．スイッチはいくらでもやりようがありそうですが，新たにDsub15ピンコネクタをつけられるくらい余裕があるのは裏側だけなんですよねー．VGAタイプ (シュリンク) なDsub15ピンコネクタを共用するようにして，変換ケーブルで普通のDsub15ピンに変換するようにしてやるのがいいかなぁ．

今まで uim.el では超狭いウィンドウに変換候補をインライン表示しようとした場合，はみ出して表示させてました．つまり，変換候補の一部が表示されない状態．そんなアホみたいに狭いウィンドウで変換する奴なんかいねーだろと思っていたので・・・が，何とどうにかしろという要望がｗ

というわけで，まず，インライン変換候補表示するにはバッファの行数が足りなくてはみ出てしまうような場合は，強制的にインライン変換候補表示を無効化するようにしてみました．これは楽勝．

次に，エコー領域に表示する変換候補を整形します．今までは，Emacs21以上の場合，Emacsのエコー領域のリサイズ機能に任せて何も考えずに変換候補を横に並べたものをエコー領域に出力していたんですが，ウィンドウの高さが極端に小さい場合，エコー領域のリサイズにも限界が生じることから，これだと場合によっては現在選択中の変換候補が見えない事態が生じてしまいよろしくありません．

そんなわけで，『変換候補をエコー領域に表示した場合に何行消費するかをこっそり確かめた上で，実際に表示してみて全部表示しきれてないようだったら切り詰める』 という処理を追加してみました．

まず，こっそり確かめるために，新たに隠しバッファを追加して，ここに変換候補を書き込んだ上で， minibuffer-window で取れるウィンドウにセットしてみて，高さを見積ります．で，次に実際に message でエコー領域に表示させて，エコー領域の高さがさっき見積もった高さと同じだったらそのまま何もせず，小さかったら全部表示できていないってことなので，切り詰め処理を行って再表示する・・・と．

次に，切り詰め処理の方ですが，こっちはエコー領域が勝手にでかくなってくれない Emacs20・XEmacs 向けの変換候補を1行に切り詰める仕組みをちょっといじればいいのですぐできるはず・・・だったんですがここではまりました．自分で書いたはずの処理が読み返してもさっぱりで，どこを「ちょっといじればいい」のかが全然わからん (;´Д`)．変数の名前は適当だし，謎の定数の足し引きをしてたりするし，何でこれでうまく動いているんだろうって感じです・・・．上の方から読み返して変数名を付け替えたりしてどうにか乗りきれましたが，できることならもう触りたくないですなぁ，この辺・・・．

そんなわけで，現状↓な感じになってます．

サービススイッチとテストスイッチをつけました．例によって，直径12mmくらいの穴を2個空けて配線するだけなんですが，手持ちのドリルソーで空けられるのは6mmまでなんで，残りの6mmは手でごりごりと・・・．結局穴あけだけで1時間くらいかかったような(´・ω・｀) ．ホールソー買おうかな・・・．

サービススイッチはいつも通りモーメンタリなスイッチなんですが，テストスイッチの方はオルタネイト (押すと凹んでONのままになって，もう1回押すと飛び出してOFFになる) なスイッチにしてみました．その方が良いケースがあるようなので・・・．

あとRGB出力に75オーム抵抗を挿入するかどうかを切り替えるスイッチも追加してみました．3回路を一発で切り替えるトグルスイッチとなると3回路2接点しかないんですかね．3回路1接点でもっと小さいのがよかったんですが，見つけられませんでした (´・ω・｀)

次は連射とボタン入れ替えかな．

朝になって玄箱への退避が終わっていたので，今度はH320にCFをつけ直して書き込み・・・しようと思ったけどよく考えたらCFを直接カードリーダーにさして書き込めばいいんじゃん・・・っていうか，カードリーダー使えば，玄箱なんかに退避せずに直接HDD→CFで転送できたじゃん＿|‾|○

まあ，仕方ないので，普通に玄箱から，T60に接続したカードリーダー経由でCFへrsync・・・遅いってレベルじゃねーぞこれは・・・(;´Д`)．読み出しの時のさらに数倍遅い感じです．半日放置してどうにか終わらせました．

そしていよいよ，ケースを閉じる作業開始．覚悟はしていましたが，やはり普通に入れると，こんな感じで(わかりにくいけど)かなりはみ出てしまいます．ギュッと閉じてガッとネジを締めれば一応閉まるんですが，バッテリやアダプタ，コネクタ部分などへの負荷が大きそうで怖いので，できればもう少し何とかしたいところ．

で，あれこれ試してみた結果，青いゴムを全部取っ払うのが一番マシっぽいという結論に(笑)．こんな風に一応変換アダプタの裏を絶縁して，青いゴムを全部取り外したH320に装着．あと，この金具を外すとさらにもう少し高さを下げられそうだったのでこちらも除去してみたり．

まだケースを閉じた際に下の方が若干浮き上がるような状態だったんですが，妥協してそのままネジを締めて作業終了．無事 RockBox も起動しました．まあ，これ以上やるならアダプタの出っ張ってるところ削るとかそういう作業になるかと・・・．

いやー，とりあえず無事完了してよかったです．使える領域がもう10G増えたのは非常に大きい．レスポンスとかバッテリの持ちとかはどうかなー．

例のWnnの変換候補がおかしい問題ですが，uim-el-agent をターミナルから上げて，以下の順で打ち込んだだけで再現可能でした．

1 0 SETENC wnn EUC-JP
1 1 NEW EUC-JP
1 2 NEW EUC-JP
1 1 CHANGE wnn
1 2 CHANGE wnn
1 1 [27 32]
1 1 [97]
1 1 [32]
1 1 UNFOCUSED
1 2 FOCUSED
1 2 [27 32]
1 2 [105]
1 2 [32]
1 2 UNFOCUSED
1 1 FOCUSED
1 1 [32]

↑はEmacsでバッファを 2個作って，片方で「あ」を変換している途中で，マウスで別のバッファに切り替えて，そっちで「い」を変換して，途中でまた「あ」の方に戻った，という状態に相当しまして ([27 32] (Alt+Space) ってのは uim-wnn の日本語入力をOnにするキーに適宜読み替えて下さい)，これをやると，本来最後の行を打ったところで「あ」とそれに対応する変換候補がわらわらと表示されなきゃならんのですが，なぜか「い」に対応する変換候補が表示されます．

ひとまず uim-el-agent 側で管理しているコンテキストのアドレスを確認してみたんですが，特に異常はなさそう．コールバック時に一緒に返ってくる，登録時に設定したコンテキストのポインタは正しいのですが，その時渡されるプリエディットなどの文字列が違ってました．一応，uim-wnnがベースとした(?)という uim-canna でも試してみたんですが，こちらでは問題は出ませんでした．uim-wnn固有の部分が怪しいのかな？

でも，それなら 他のブリッジとかでも再現してもよさそうなものなんですが，gtk-demo を2個起動して，同じようなことをやっても再現しないんですよねこれ．uim-el-agentがAPIの使い方間違えてるのかなぁ・・・？ いや，でもそしたら Wnn 以外でも問題発生するだろうし・・・．ひょっとして単一のプロセス内で2個コンテキスト作ると駄目なのか？

というわけで，gtk-demoを1個だけ上げて，その中で HyperText と Multiple Views の両方を開いて，それぞれで「あ」と「い」を並行して変換してみたところ・・・再現したッ！ というわけで，uim-wnn の中で，本来 uim のコンテキスト毎に独立していなければならない何かの変数を使い回ししちゃうような記述になっているのではないかと予想．kinput2 はそういう使われ方しなそうな気がするし・・・(続く？)

ちなみに，これまでの話とは多分関係ないんですが，気がついたらWnnで「い」を変換すると，「い」が超いっぱい出るように(笑)

一瞬イタリアでの検索でも出るようになっていたんですが，すぐ直っちゃいました．