予算の都合からディスペロウは後回し……そう思いつつロードゲイルも買えてないんだよなぁ。詳しい事はいずれゾイドページ*1に載せるとして、簡単な印象を。
ゼロとイクスがかなりそのまんまだったので期待していなかったのだが、BFと凱龍輝は差別化に十分成功している。エヴォフライヤーはウネンラギアの強化型で、レオブレイズで言うレオストライカーにあたるが、モチーフがウネンラギアからミクロラプトルへ変更になってしまっている。で、なんと言うか、よっぽど予算が削られているのだろうか？
成形色は妙にチープだし、ブロック数は妙に少ないし、Jランナーが廃止でジョイントは通常パーツのランナーに最小限しか入っていないし。頭にとさかが付いたのは構わないが顔は妙に不細工になったし、コクピットがBLOX企画段階のセンターブロックっぽくなったのはいいが妙に幅広でブロック二つ分あるし、尻尾は意味不明なパーツになったし、爪もやけにチープだし、ウネンラギアと較べると格好悪く見える。
レオストライカーは色使いが変だったけど、顔はスマートになってたし、各パーツが扱いやすくなっていた。ひきかえこっちは何だか悪くなっている気がする。ラプトルタイプとして初めて羽の表現にマグネッサーシステムを用意したのは評価したいんだがなぁ。
Mac OS Xはmod_perlを既にインストール済みらしいのでhttpd.confを書き換え（と言ってもコメントアウトされている記述を引っ張り込むだけ）。これがうまく動くかない。検索してみたのだが、Another HTML-lintがmod_perlで障害があったと言う話も動いたと言う話も見つからない。……誰もこの組み合わせで試していないと言う事だろうか？
バックスラッシュ（実際は￥記号だけど）をクエスチョンマークにして送ってしまうらしいので（おかげで検索結果が意味不明に）、しばらくNucleusでの入力はCaminoを使ってみたのだけど、そのCaminoにしてもかなりの確率で文字化けてしまうっぽい。ランダムに二バイト文字が一つだけ分解されてしまう。結局、一番の選択肢はIE5:macと言う事に。でもIE5:macはapplication/xhtml+xmlに対応していないんだよなぁ。
通常検索を実行するとマッチした文字列が選択される。普通のテキストエディタだと検索作業は単純に選択範囲の直後を始点にするので、これを利用して最初から文字列を選択しておき対象を限定する方法があるが、Safariの場合そうはいかない。
Safariは検索の始点を目に見える選択範囲とはまた別に持っている。これが最初わからずに困った。つまり、他のアプリで当たり前に使える方法がSafariでは使えないと言う事。で、何故Safariはわざわざ他のアプリケーションとは異なる実装をしているのか？ 例えば始点からページの終わりまでにマッチしなかった場合に最初は警告し、二回目はページの先頭から検索をはじめる、と言う挙動を可能にする為だろう。これはこれで単純に選択範囲を始点とする他のアプリには不可能なインテリジェントな挙動なのだが、他の挙動と違うのは困る。
もう一つ、Mac OS Xは検索文字列用のクリップボードを独立して持っている話は以前書いたが、Safariはアドレスバー横のGoogle検索欄に打ち込んだ文字列もちゃんとそっちへクリップしてくれる。ただ、個人的にGoogle検索する時は大概複数のキーワードを使うので、そのままだとあまり意味が無かったり。かと言って勝手に最初のキーワードだけをクリップするのが良いとも思えないし。
Wikiの編集ページに検索から直接飛んで来る。何でわざわざ奥のページ（しかもtextarea要素の中身）にマッチするんだか。編集ページにロボット除けのmetaを埋めるか、該当リファラを必須にするか。
*1 XSLTが思うように完成していないので未だダークスパイナーのレビューが上げられない（泣）