あーありがち

過去の日記 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ 久しぶりに完全オフ

まー毎週ちゃんと休日はあるんですが、試験とか試験勉強とかなんだかんだでうまいこと身体を休めることができずにしばらくきてました。やっと完全休養日。たった一日。おいこら。

なんかいろいろやりたいことがあったような気がするんだけど、なんだったかもう思い出せないしやる気も起きない。

まーそんな日も必要だなってこった。なんか fink とか ports とか地味にアップデートしながらボー。

_ emacs-w3m で referer は吐けないのか？

そんなにヘビーに使っているわけでもなかったので今まで w3m + Emacs で textarea を編集する際は普通に w3m から Emacs を起動して利用していたんだけど、ふと思い立って w3m-el を入れて全部 Emacs から作業するようにしてみた。

tDiary の CSRF 対策に引っかかって書いた内容全部飛ばしちまったorz

あとで分かったことだけど、どうも w3m から Emacs を起動するか、Emacs から w3m を起動するかの違いでしかないっぽいので、21.3.5 なら起動も速いし今まで通りの使い方でいいような気がしてきた。この方がマウスも普通に使えるし。

それより w3m.org がソースをそのまま吐いているのは何が起きているんだろうか。

ついでに以前 mule-ucs を組み込んで激重になった Debian 上の Emacs でも w3m-el なら快適だーと思っていたが、今度は textarea のレンダリングがおかしい。おうおうおう。そこが目的なんじゃい、emacs-w3m さんよぉ*1。

ということで強権発動して、システムワイドでいきなり mule-ucs を読み込もうとする startup の elisp を外した。必要なときに自分で require することにして起動を軽くし、こっちも w3m から Emacs を起動する方式に変更。同時にあれこれ起動を重くする要素を見直して少しでも快適に作業できるようにしてみた。

結局、元通りってことなんだな。

※ tDiary の設定をいじればいいじゃんとも思うんだけど、まぁそもそも emacs-w3m の操作性がちょっと趣味に合わないので、無理に使わなくてもいいやと思ったのでした。そうこう言っててまたそっちに傾くかもしれないんだけど。

_ WCLはもう一手間加えないとダメだな

しつこく Yahoo! Widgets の Widget Class Library ですが。

とりあえずライブラリの存在をチェックして include してグローバルな lib にオブジェクトを作ってやるなんつー単純な作業を毎回書くのはいやなので、それだけをやるコードを書いた。

ついでにどんなコンポーネントがあるのかだけでもライブラリ自身にリストアップしてもらおうと components(), subcomponents() を勝手に追加。（要はファイルシステムをなめて .js ファイルかディレクトリかチェックして配列を返すだけ。）

雰囲気がつかめてきて機嫌がよくなってくる。しかしその先へ行こうとサンプルを眺めてげんなり。

• まず Yahoo.Controls.Theme コンストラクタに Theme の存在するパスを教えてやる（えぇっ!?）
  • しかもそのためには Yahoo.Controls クラスのリソースのパスを getResourcePath で取得したうえで、その中の Themes ディレクトリを指定する必要がある（マジっすか）
  • つまりこういうこと new Yahoo.Controls.Theme( lib.getResourcePath( 'Yahoo.Controls' ) + '/Themes' )
  • こんなのグローバルな lib を自分たちで汚してるんだし、オブジェクトの中で解決してくれよ
• できたオブジェクトに theme 名を与える
• 各コントロールのコンストラクタにはすべてこの theme オブジェクトを与える
• 各コントロールのパラメータはできあがったオブジェクトに対して一つ一つ丁寧にセットしてやる

frmMain = new Yahoo.Controls.Form(theme);
frmMain.text = "Widget Class Library Control Sample";
frmMain.width = 350;
frmMain.height = 400;
...
lblPrompt1 = new Yahoo.Controls.Label(frmMain.theme);
lblPrompt1.autoSize = true;
lblPrompt1.left = 8;
...

以下コントロール分くり返し。

……。

いやぁ。自分で画像作らなくていいのはありがたいよ？ ありがたいんだけど、なんでこんなめんどくさいんだよぅ。なーんつーかこう、バラバラな感じ。かといって粗結合で扱いやすいよ！とかでもない。あくまで縦横無尽に共依存。

どないやねん。どないやねーん。

なんかパラメータとかもさ、JSON でドーンとセットしたいじゃんよ。まぁそういうの書けばいいんだと思うけどさ。ぐるぐる回して setter があったらそれに放り込むようなやつ？ まぁ自分に書けるかどうか分かんないけどさ*1。しかもこのライブラリの setter, getter の書き方って deprecated ですよ？ orz

cf. Core JavaScript 1.5 Guide:Creating New Objects:Defining Getters and Setters - MDC

他にもリファレンスを眺めてみると obosolete なのに Widget Class Library のサンプルにはバンバン出てくる書き方とかあったりして、そういうのどうなのよ？とかね。気になるところがボロボロと出てきますね、これ。

たぶんその辺の気持ち悪さが解消されればめっちゃ便利になるんじゃないかと期待はしてるんだけどなぁ。自分で書かなきゃいけないんですかねぇ。WCL そのもののバージョンアップなんてそんなすぐにはないですよね…。

_ MacOSX の open を GNOME で

もうそのまんま gnome-open だった。

Twitter / UI: alias open='gnome-open' はあ ...

ただ alias って Emacs の Dired では解釈されないらしく、どうしても標準で入ってる open*1 の方が立ち上がっちゃって悲しい。

ちなみに OSX と同じく標準状態で PDF が手軽に作成できてるのは嬉しいんだけど、~/PDF/ に入るのはなんかもうちょっと分かりやすく GUI から設定できてもいいんじゃないかと思った。

Twitter / Takeru Naito: @wtnabe /etc/cups/cups-pdf ...

_ git で svn status のようなもの

git ls-files にいろいろオプションがある。

-m(--modified)

修正されているファイル。svn では M と出てくるやつ。

-o(--others)

管理対象外のファイル。svn では ? と出てくるやつ。--directory を付けると、丸ごと others なディレクトリは DIRECTORY/ までの表示になる。必要以上に出てこないのでうざくない。こっちがデフォルトの方が親切なような気もする。

-t

管理されているファイルの status が取れる。これこそが本当に svn status 相当。のはずなんだけど、見てる情報が違うらしく、上の二つの情報を合わせたものにはなぜかならない。どーもこの辺、git のマニュアルが不備なのか自分の理解が足りないのかよく分からんのだよな。

あと svn info 相当の情報も取り方がよく分からない。git remote -v でずいぶんあっさりした情報は取れるんだけどねぇ。