たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
Thunderbirdでは、複数のメールアカウントを設定している場合、メールを返信しようとすると、そのメールを受信したアカウントの差出人設定が自動的に選択されるそうだ。
しかし残念ながら僕は仕事用のアカウント一つだけしか作っていなくて、プライベートのアドレスで受信したメールを仕事用アドレスにも転送するという使い方をしている。差出人設定は仕事用とプライベート用の2つを設定してあるけど、返信する時は受信アカウントのデフォルトの差出人(=仕事用アドレス)が選択されてしまうので、手動で差出人を選択し直してやらなくてはならない。うっかりそれを忘れると、プライベートで受信したメールに仕事用アドレスで返信することになってしまう。(仕事中にプライベートでメール書くなよって? いや、仕事の時以外でもこのマシン使うんで……例えば出先とかね)
どがんせんといかんと思って検索してみたら、Correct Identityという拡張機能が見つかった。これを入れておくと、メールに返信する時、受信アカウントに関係なく、メールの宛先(CCでも可)に設定されたアドレスに対応する差出人が自動的に選択されるようになる。
ただ、転送メールを使っていて受信アドレスと返信アドレスが異なる、という僕のような人は注意が必要だ。
僕は公開してるアドレスはずっと piro@p.club.ne.jp で通してるけど、これは転送専用のアドレスで、昔はCC-Netのアドレスに、今はさくらのレンタルサーバ付属のアドレスに転送されるようになっている(それをさらにGMailで受信して、仕事用アドレス宛に自動転送する、ということをしている)。しかし、さくらのレンタルサーバのアドレスはFrom:フィールドのアドレスが上記転送アドレスになっているとメールを送れないので、差出人情報はそっちのアドレスで作ってある。このままだと、piro@p.club.ne.jpで受信したメールに対応する差出人が見つからないということになってしまう。
幸い、Correct Identityにはエイリアスの設定機能があった。ここに自分宛のメールの宛先に設定されることがあるアドレスを改行区切りで列挙しておく(これに気付かずスペース区切りやカンマ区切りで書いてしまって「なんで動かないんだ」としばらく詰まった)と、受信したメールの「宛先」がpiro@p.club.ne.jpになっていても、対応する差出人としてさくらのレンタルサーバのアドレスが設定された差出人が選択されるようになる。
ほんとに何でもあるね……なんか本気でThunderbirdから離れられなくなりそうだ。
ここまでのカスタマイズまとめは以前書いたエントリにある。
Thunderbirdで受信メールをスレッド表示してると、スレッドのネストが深くなりすぎて後の方のメールが見えない状況になってきてしまったので、インデント幅を小さくした。以下の内容をThunderbirdのプロファイルフォルダ内のchromeフォルダ(無ければ新規作成)の中のuserChrome.css(これも無ければ新規作成)に以下の内容を書く。
@-moz-document url(chrome://messenger/content/messenger.xul) {
treechildren::-moz-tree-indentation {
width: 9px !important;
}
treechildren::-moz-tree-twisty {
padding-right: 0px !important;
}
treechildren::-moz-tree-cell-text(colNodeName) {
margin-left: 1px !important;
}
}
DOM Inspectorのインデント幅を減らすやつそのまんまですな。
ちなみに上記のままだとフォルダペインのインデント幅も小さくなってしまいます(僕はその方が都合がいい)が、スレッドペインだけに反映させたい場合はtreechildren
という箇所を#threadTree treechildren
とかなんとか書き換えてください。
Second Search更新した。Firefox 3(Beta3)とThunderbird 2に対応。
Thunderbird対応にあたって、全体的にコードに手を入れた。Firefoxだけでしか使わない部分とThunderbirdでしか使わない部分と両方で使う部分の3つにファイルを分割している。似たような構造の物に対してはこれで比較的楽に対応できるようになったんじゃないかと思う。
Firefox 3については、Placesへの対応がメイン。キーワードを設定されたブックマークを検索エンジンと同等に扱うという機能がSecond Searchにはあるんだけど、僕以外にどれだけの人が使ってるんだろう。
あと、「他の検索エンジン」サブメニューのあたりのコードもだいぶ書き直した。この辺はほんとは特に触る予定はなかったんだけど、Organize Search Enginesとの競合の解消も兼ねて、なるべく汎用的になるように変更している。っていうかテストしててなーんかうまく動かないなーと思って不思議だったんだけど、よく調べてみたらOSEの側にSecond Search用のハックが入っててそれが干渉していた。僕のアドオンのためにわざわざハック用のコードを書いてくれるなんて……よくあんなスパゲッティもスパゲッティなコードを解読してくれたもんだなぁ……と嬉しく思ったりもしたけど、このままだとせっかく修正したのがきちんと動いてくれないので、動くようにするパッチを作者の人に送りつけてみたり。
nsIMsgDBHdrとnsIMsgFolderからメールの本文を文字列として取得する方法をあれこれ試してみてこんな感じのところに辿り着きましたとさ。
検索を開始したタイミングでヘッダ情報を一気に収集するという現状の仕様だと、フォルダ内に数千件とかメールが溜まってる人はまず間違いなく死亡するので、フォルダの内容を表示したタイミングでバックグラウンドでちまちまとヘッダ情報を収集するようにして、ついでに、その収集結果をMozStorageで保存するようにしてみてるんだけど。
今の所、一つのフォルダにつき一つのレコードとして、「Subjectだけ集めたもの」「Toだけ集めたもの」のような文字列をそれぞれフィールドに保存してるんだけど、これもあんまりでっかくなりすぎるとまずいですよねえ多分。仮にSubjectが10文字のメールが1000件あったとすると、20~40KBとかそれくらいになるのかな? 3000件もあれば100KBはいってもおかしくない。これって大丈夫なんだろうか。
えーと。SQLiteの制限事項によると、SQLiteデフォルトでの文字列の最大長は1ビリオン(1000000000)バイト……えーと、だいたい1GBくらい? Firefoxのソースツリーを検索してもSQLITE_MAX_LENGTHという文字列は登場しないようなので(というのは全然根拠にならんのだけど)、このデフォルト値のまんまなんだとしたら、パフォーマンスはさておきとりあえずこのままでも動くことは動くのかな?
というか別にSQLite使う必要は必ずしもないんですけどね。なんとなく最近無駄に多用する癖が……
ということで、アップデートしました。余りに久しぶりの更新すぎて更新の手順を忘れてしまっていたのはここだけの秘密です。
やってることとしては、リンク先にも書いてるけど、まず検索対象のフォルダのメール全部を走査してヘッダ情報を収集。次に、それを文字列として連結して検索用のデータを作成。それに対してXUL/Migemoで生成した正規表現でマッチングを行い、ヒットした箇所を抜き出して、それを検索語句としてThunderbirdに渡す。という手順で、ローマ字入力でのメール検索を実現しています。今のところヘッダ情報しか収集していないので、本文内に含まれる単語は検索できません。要約とかをきちんとキャッシュするようにすればできるのかもしれないけど、そこまでやると大変そうなので今のところはここまで。
ハードディスクが逝ってしまった後に再構築した環境でテストしている都合上、大量のメールがある状況でどのくらい重くなるのかは未検証です。ヤバいくらい遅くなる場合は、設定ダイアログから「メールの検索でXUL/Migemoを使用する」のチェックを無効にしてください。
んぁ。意図したわけではなかったんだけど肉の日リリースになった……
XUL/Migemoでメールの検索をできるようにしてみたいな、と思って試してみた。
メールの検索はOR検索はできるようなので、キャラクタクラスやグルーピングを展開して単語のリストを生成してOR検索したらいけるかな?と思ってやってみたんだけど、ローマ字入力から単語のリストを作る所までで数百ミリ秒くらいの遅延というのはまあ許したとしても、そこから先の実際に検索にぶち込む所で重すぎてThunderbirdが落ちた。そりゃ9000ワードをOR検索とか、いくらC++で書かれた処理が速いといっても限度があるわ。
というわけで正攻法は無理なので別のやり方を考えないといかんですね。やっぱアレかな、検索対象のメールすべてのヘッダを一旦文字列に取り出してそこに検索をかけてから、ヒット箇所の単語を実際の検索に投げるという、いかにもXUL/Migemoらしい(plus7さんよくこんなやり方を思いついたもんだ)やり方で行くしかないのかな。
どーでもいいけどこの正規表現を単語のリストに変換する処理、自分で書いておきながら、どういう理屈で動いているのかさっぱり分からんです。
追記。前述したヘッダを一旦文字列に取り出して云々のやり方を実装してみたら、数十件程度ならわりとストレスなく動くようになった。1フォルダに数百件、数千件とかのメールが溜まってる環境だとやばいかもだけど。
Firefoxの環境はデスクトップ百景を参照。
新マシンへの移行と同時にThunderbirdの本格的な利用を開始して、さっそく不満タラタラになったのでアドオンを漁ってみた。
スレッド表示してる時にソートできなくなる件について、あまりにあんまりだと思ってアドオンを作り初めてからふと「Thunderbird スレッド ソート」で検索してみたら、about:configでmailnews.thread_pane_column_unthreadsをfalseにすればよいと書かれた記事を発見した。こんなのデフォルトでfalseにしといてくれよ……
スレッドペインのコンテキストメニューで一番上の項目が「返信」じゃなくて「新しいウィンドウで開く」になってるせいで、無駄にウィンドウを開いてしまってイライラ。なのでuserChrome.cssで項目を消した。ついでにDOM Inspectorのインデントも減らしてみた。スレッド表示のネストが深くなったときに見にくくなるので、スレッドペインのインデントも変えるようにした。
#threadPaneContext-openNewWindow,
#threadPaneContext-sep-open {
display: none !important;
}
@-moz-document url(chrome://inspector/content/viewers/dom/dom.xul),
url-prefix(chrome://messenger/content/) {
treechildren::-moz-tree-indentation {
width: 9px !important;
}
treechildren::-moz-tree-twisty {
padding-right: 0px !important;
}
treechildren::-moz-tree-cell-text(colNodeName) {
margin-left: 1px !important;
}
}
仕事用マシンにしてたLet's note W2のHDDがハードウェア的にいかれてしまったらしい、ということで新マシンを買ってもらえました。Let's note W7です。Windows Vistaがプリインストールされてるんだけど、例によってLinux環境が必要なのでUbuntu 7.10 Gutsy Gibbonを入れました。
以下、詰まったところと設定。
Section "Module" Load "xgl" Load "dri" EndSection
#!/bin/sh
minimum=5
display='-display :0.0'
arg=`echo $1 | sed -r -e 's/([+-])([^ ])/\1 \2/'`
echo 'from' `xbacklight -get $display`
current=`xbacklight -get $display | sed -r -e 's/..+$//'`
new=`expr $current $arg`
if [ `expr $new \< $minimum` = '1' ]; then new=$minimum; fi
xbacklight -set $new $display
echo 'to' `xbacklight -get $display`
大体こんなところだろうか? あとは今まで使ってたソフトの類が全部入れ直しなので、設定がどうしようもなくめんどいです……
あと、これを機にThunderbirdをメインのメールソフトとして使い始めてみたんだけど、メールからフィルタを自動作成できないとか、フィルタを設定する時に移動先フォルダを先に作っておかないと選択できない(移動先フォルダをその場で新規作成できない)とか、いちいち細かいところで痒いところに手が届かなくてムキーとなる。Sylpheedはその辺よかったんだけどなぁ……って、自分でガンガン要望を挙げてそうしてもらったから当たり前なんだけど。あとスレッド表示を有効にすると他のカラムでソートできなくなるというのは致命的。アドオンでどうにかなるんだろうか?
Thunderbird 2でメッセージ内検索がFind As You Type/Find Barベースの物に変わったということで、これから仕事でTb 2をいじくり回す機会も増えてきそうだからその練習も兼ねて(?)、XUL/Migemo勝手改造版をTb 2に対応させてみた。あと、Tb 2対応のためにコードの一部を若干抽象化したので、その勢いで同じくFind Barを使ってる「ソースの表示」ウィンドウでもXUL/Migemoを使えるようにしてみた。
新規プロファイルでTb 2(2.0正式版リリースに向けた最新のナイトリービルド)を起動して気がついたけど、「戻る」「進む」って初期状態でツールバーに表示されてるのね。カスタマイズで自分で追加しなきゃいけないって聞いてたから「ありえねー」と思ってたけど、単に旧バージョンからプロファイルを引き継いだ人だけがそうなるってことだったのか。
あとGmailのアカウントを簡単に設定できるようになってた(名前とメールアドレスを入力するだけでOK)のは地味に嬉しい。内部的にはただのアカウント設定のテンプレート内蔵ってことなんだけど、こんな調子で有名どころのサービスを一通り網羅してくれてれば、個人ユーザ向けにお薦めできるポイントになると思うんだがなあ。