はじめてのにき

_ 端末とキーボード

screen の ^t 2度押しとか無駄だなーと思ってたので Meta とのバインドを適当に .mlterm/key に書く。

Mod+x="\x14\x18"
Mod+bracketleft="\x14["
Mod+s="\x14\x14"
Mod+t="\x14\x14"
Mod+c="\x14\x03"
#Mod+d="\x14\x04"
Mod+0="\x140"
Mod+1="\x141"
Mod+2="\x142"
Mod+3="\x143"
Mod+4="\x144"
Mod+5="\x145"
Mod+6="\x146"
Mod+7="\x147"
Mod+8="\x148"
Mod+9="\x149"

Mod+d は普通に使ってるのと、 あとまぁ使う頻度が少ないので ^t でいいやということで。

本当は super 使おうと思ってたんだけど mlterm がサポートしてないから自分で実装するのもめんどいし、 あと使ってない Mod+? が結構あるからいいか、と。

参考にしたのは新山さんの設定ファイル。

http://www.unixuser.org/~euske/doc/bashtips/bashrc.html

次は screen 。

http://d.hatena.ne.jp/emacsjjj/20050717/p1

を参考にさせてもらって Return で xclip につっこめるようにする。

bindkey -m ' ' eval 'msgwait 0' 'stuff \040' 'writebuf /tmp/scr' 'exec !!! __scr2x2'
bindkey -m ^M eval 'msgwait 0' 'stuff \015' 'writebuf /tmp/scr' 'exec !!! __scr2x2'

__scr2x2 はこんな感じで。 nkf -w が無いと日本語コピペに困る

#!/bin/sh

nkf -w /tmp/scr | xclip
screen -X msgwait 1

ついでに bindkey -m つながりで

bindkey -m ^v eval 'stuff \004'

をよく間違えるっていうか ^d は覚えにくすぎるので。

あと screen にシステムモニタ出すコマンドは

screen -X hardstatus alwayslastline '%` [%Lw]'
screen -X backtick 0 0 0 /home/i/test/screen_monitor -s

なんだけど、これは画面右上の screen でだけ起きるようにしてやりたい。 まぁ sevilwm に問いあわせればいいと思った…

が、なんかそう X の Window から pid をひく方法って無い気がするんだよなー 的な理由で precmd にひっかけた ruby script で sevilwm の focus の当たってる window を調べて… 的なアプローチで適当に処理した。適当。

あーいや別の理由で screen の PID から window を調べるのは いずれにせよ欲しかったんだよなぁ。 screen -x と -r がわけわからんというのがその理由で。

やまぁ /tmp/pid.db とかに screen の pid 使って db 書いていけばいいか… screen-ls とかいうコマンドを作って、

There are screens on:
        19611.pts-10.u4 (Attached) mlterm:3 1x1+564+340 vdesk=2 [rdic@/home/i cd
 '/home/i'@/home/i]
        3468.pts-18.u4  (Detached)
        3255.pts-2.u4   (Detached)
        3236.pts-0.u4   (Detached)
        17167.pts-16.u4 (Attached) mlterm:4 1115x709+564+340 vdesk=2 [vi@/home/i

]

とか出るようになった。 まぁとりあえずこんなもんでいいか…

あとなんかたまに mirc が死んでたりとかするし、 そもそも動かしてるサーバの数がもう把握しきれんため、 daemontools あたりの使いかたを覚えるべき。

それと sevilwm の multi display とか、 screen_monitor の cia 化とか

(07:11)

_ 文体診断

http://logoon.org/

面白いなぁ。

何が面白いって、 はてなとかから適当にコードの無い文章を持ってきて 診断してしてもらうと、 必ず、

• 1 文章の読みやすさ E 一文が長い
• 2 文章の硬さ E 文章が柔かい
• 3 文章の表現力 A とても表現力豊か
• 4 文章の個性 A とても個性的

という診断が出ること。 個性的とか表現力とかは、単に、プログラム用語のせいかなーと思ったんだけど、 引越し記録 (http://shinh.skr.jp/m/?date=20100601#p02) とかでも 同じ結果が出るんだよなぁ。

適当に他の人の日記とかをはってみると、 だいたい似たような傾向があるみたいだ。 一文が長いとかは自覚してたんだけど、 まぁ別に気にしなくてもいいのかな。

適当に入れてみた中では、 まめさんのこれとかは高評価だった。

http://d.hatena.ne.jp/ku-ma-me/20100322/p4

やりました。 この文章ではなるべく頻繁に句読点を入れるようにしてたのですが、 読みやすいと言ってもらえました。 やりました。

しかしこれ、作家とかと比較してるから、 どんな文章でも表現力豊かで個性的に なっちゃうんじゃないかなー。

(16:29)

_ BNE

http://ja.wikipedia.org/wiki/BNE%E5%8F%82%E4%B8%8A

そういえばよく見かけるなと思って、 少し検索してみたことがあった。 よく見かけるどころか、 海外などでも見たことがあるように思う。

しかし、検索の結果は芳しくなく、 何が何やらわからない、 ということが判明しただけなのである。

…ちょっと硬く書こうと努力したけど、 全然やわらかいのまんまだった。 なんていうかコレ英語とか未知語の数で硬さが決まってるんじゃないかな。 コードとか入ると一気に硬くなるし。

BNE は正直ちょっと面白いなーと思った。 なんというか夢がある。 まぁ迷惑は迷惑なんだろうな。

(19:19)

_ Omium

http://www.youtube.com/watch?v=s5U-SRDD064

via http://d.hatena.ne.jp/ABA/20100609#c1276092770

面白そう。

(19:35)

_ sevilwm の window switch

前から思ってたがこれはダメだ。

> unixcat /tmp/sevilwm_:0.0/info G vdesk=1
sevilwm x=2832 y=1050 vdesk=1
mlterm:4 1114x1+564+340 vdesk=1
mlterm:3 1x1+564+340 vdesk=1
mlterm:0 561x1+564+340 vdesk=1 FOCUSED
Emacs:2 1x347+583+702 vdesk=1
Emacs:1 551x348+581+700 vdesk=1
Google-chrome:0 1681x1+1149+861 vdesk=1
Emacs:0 1097x348+581+700 vdesk=1

これの Emacs:0 => Google-chrome の遷移が右でできない。 mlterm:4 の方に行ってしまう。

つまりえーと…

• Emacs:0 1097x348+581+700 中心 (1387, 698)
• mlterm:4 1114x1+564+340 中心 (1396, 171)
• chrome:0 1681x1+1149+861 中心 (2225, 432)

なので、右方向の遷移はえーと

100000 - (dstX - srcX) - abs(dstY - srcY) * 3

で評価されるらしいので、

mlterm4: 98410
Google-chrome0: 98331

となって y の差分が大きいものの、 x の差分が小さい mlterm が勝ってしまう、と。

まぁどう考えてもこの評価関数がひどい。 こんなもので良い理由がどこにも無い。

どう考えても角度を使うべき。 要は角度差が小さくて距離も短い対象が良い。 しかしまぁその二者をどう合成するかはマジメに考えないといけない。

mlterm

irb(main):015:0> Math.atan2(698-171, 1387-1396) / 3.14159 * 180
=> 90.9784675354791
irb(main):013:0> Math.sqrt((171-698)**2 + (1396-1387)**2)
=> 527.076844492338

chrome

irb(main):016:0> Math.atan2(432-171, 2225-1396) / 3.14159 * 180
=> 17.4759534949213
irb(main):017:0> Math.sqrt((171-432)**2 + (1396-2225)**2)
=> 869.115642478031

直感的に角度は2乗するといい気がする。 ただ degree を単に2乗すると 30度のズレが 900 ピクセルの距離に相当してしまうので、 うーんこれはちょっと大きすぎるかもしれない。

ちょっと実験してみると、なんか意外な感じで、 15 度くらいずれてたらもう飛ばしてくれてもいいよと感じるみたいだった。 それだと角度の 2 乗でも足りないか…

実装してみた。 なんか普通に角度の自乗プラス距離で悪くないみたいだ。 しばらくこれで試してみようと思う。

(22:14)

_ xsel -i -b

xclip のかわりにコレを使うと gtk のクリップボードにも反映されるみたいだ。

http://highmtworks.spaces.live.com/Blog/cns!3B475A7E547A2260!277.entry

より。

(22:39)