UA 文字列を Javascript から得るにあたり検索をかけてみたのだけど、UA 文字列にある文字列 (eg. “MSIE”) があるか調べるときに String.prototype.indexOf の結果が -1 であるかを調べているのが多かった。これはやっぱ String.prototype.match だと遅いとかそういう問題があるからなのだろうか……なんかダサいので今回自分は String.prototype.match を使ったけど、どうなんだろ。
if (navigator.userAgent.indexOf("MSIE") != -1)
// do something for MSIE if (navigator.userAgent.match(/MSIE/)) // do something for MSIE
さらに && とか使おうとすると演算子の優先順位 (よく忘れる) とか考えることになって面倒臭い……
pre に現れるコードを Javascript で着色 (Javascript でやってるのはマークアップ) してみる。重い？
少し前からこれがやってみたかったので class 属性に使用してる言語を書いていたりした。言語ごとにトークンを使いわけたようと思ってたわけだけど、実際そこまでやるのってどうなのよ、とか思い始めた。そのうちやってみて、いけそうだったら採用してみよう。
現状でもかなり重い気が……長くとれるトークンを増やせば (ループ量が減って) 軽くなるかもしれないけど微妙。実際一文字ずつループまわしてるからなぁ。やりすぎか。
Ruby と ECMAScript は別のトークンテーブル使うようにしてみた。別にパースしてるわけじゃない (スキャンだけ) なので微妙にアレな状況が既にいくつか思いつくわけですが……例えば式展開の引数で括ってるクオーテーションつかっちゃうとかが絶対おかしくなる。
それとループ回数を減らすために /[a-z][a-z0-9]*/i は identifer ってことにしてスキップしてる。
Lisp と XML もすっごい適当に加えた。
サンプル 重いので移した。
正規表現はブラウザ毎の違いが殆どない気もする。気付いてないだけかもしれないけど。
FF で右クリックから View Selection Source すると内部 DOM の内容もソースとして出てくるのが役に立った……
そもそもスキャナの実装が激しく間違ってたので修正。根本的な部分を変えたのでバグがあるかもしれない。
Audioscrobbler で最近 Recent Tracks に聞いてない曲が混ざることがある。バンプ が車輪の唄のシングルカットしてたなんてそもそも知らないのに、それのカップリングのやつが Recent Tracks に混ざっていたりする。
無作為に混ざっているわけじゃないらしく？同じアーティスト聞いてると混ざるみたい？