vimrc 會比任何 plugin 都還要先執行，所以如果有什麼工作是想要在 plugin 讀完後才做的，就不能直接寫在 vimrc 裡面，以我的例子，我想要在某些 plugin 有安裝，該 plugin 的命令確實存在的話，才去另外做這些命令的 mapping ，例如：

if exists(":Align")
    com! -bang -range -nargs=* A <line1>,<line2>call Align#Align(<bang>0,<q-args>)
endif

這段程式直接放在 vimrc 裡面的話， if 判斷都不會成立，所以我的作法是丟到 function 裡面，然後放到 VimEnter 這個 auto command 的事件執行：

function AfterStart ()

" plugin commands
if exists(":Align")
    com! -bang -range -nargs=* A <line1>,<line2>call Align#Align(<bang>0,<q-args>)
endif

endfunction
autocmd VimEnter * :call AfterStart()

jQuery 1.4 有個改變應該很少有人注意到，我也是最近剛好有需求才發現，就是直接執行 jQuery 不傳任何參數：

jQuery();

結果會傳回一個 空的 jQuery set ，不過這在 1.4 以前的版本會傳回 document ，這樣的修改我覺得是比較好的，因為以前完全沒辦法產生空的 jQuery set，如果要自己做 jQuery set 會比較方便，除了把要的 DOM 節點抓好放陣列丟給 jQuery 外還多了個建立空的 jQuery set 後一個一個把要的節點丟進去的方法，另一個優點是這樣確保 jQuery function 傳回來的物件是同樣的類型。

WAI-ARIA 全名是 Accessible Rich Internet Applications Suite，是 WAI 正在制定中的規範之一，對象是網路應用程式，像是 gmail、各種 CMS 等，它在WAI 制定的各種規範中，是唯一縮寫名稱用 WAI- 開頭的，一直很好奇為什麼，前幾天寫信去問也得到了答覆：

Short answer: Because the acronym ARIA is used for other things, we use WAI-ARIA.

結果和 J長輩 猜的一樣是因為 A R I A 太常見了，所以加上 WAI- 。

前幾天在測試 each 和 for 迴圈的效率時，意外的一直得到 each 效率比較好的奇怪現象，搞了兩天才找到原因。

each 這種方法效率會比 for 迴圈還要低主要是因為它是把要做的事情用 function 傳進去，多了一個 function call 和一層 function scope，要對變數作存取時會多了到不同層 scope 尋找的差，所以理論上它會比 for 迴圈還要慢。除此之外，DOM 本身就很慢了，當然 DOM NodeList 的操作和存取也不會快到哪去，所以像 Sizzle 引擎就會把 DOM NodeList 轉成陣列再傳回來，而我測試 each 和 for 兩者的效率時，也就是這個部分產生了非預想的結果，根據測試結果 Google V8 和 Firefox 3.6 的 Tracemonkey 這兩個會編譯 JS 的引擎，第二次對同樣內容的 DOM collection 轉陣列的動作時會比第一次還要快，而且大約是兩倍快，測試的基準是第一次用 getElementsByTagName 抓 <span> ，第二次用 jQuery，內部也是一樣用 getElementsByTagName ，並且小修改過 DOM 結構後再做一樣的事情也是會比第一次還快，並且，不管是用 slice 還是 for 迴圈一個元素一個元素推到陣列裡面都沒差很多，一開始因為測試都是對同樣的標籤作處理，結果先測的方法就佔了劣勢，就像是美食漫畫一樣，先上菜的都會輸一樣，不過我對編譯器的怎樣做最佳化的方法不熟，所以這兩個引擎是怎麼辦到的就不清楚了。

除了這點之外，還有一些不算小發現的小發現，第一個就是 Firefox 3.6 還是好慢，詳細數據我忘了，不過和 V8、Safari 比起來差距還是不小，然後就是 IE 超．級．慢！！第二是 each 真的比較慢，不過在現在 JS 引擎普遍暴力的情況下差距其實不明顯（不過 NodeList 和陣列的差距還是有）。第三是前面已經講過的 Sizzle 回傳的是陣列而不是 NodeList ，雖然實際上想要自己組合 NodeList 似乎也是不可能的。最後是 jQeury 可以用 $("span")[0] 這種寫法來直接存取 DOM 節點，不過它並不是陣列，要轉成純陣列可以用 $("span").get() ，只是測試過後發現沒有比較快，因為還要重新轉一次陣列，這裡損失的時間也不會比直接存取來的少。

dive into mark 在去年11月有一篇文章 Why do we have an IMG element? ，裡面翻出了很多當初 HTML 剛起步時的討論，當時就在針對網頁上的媒體內容要怎樣放進去作了不少爭論，過程有興趣的可以自己去看，結果還是先下手為強，先做出來的贏， mark 歸納出的幾點結論中有一點蠻有趣的：「HTML一直都是瀏覽器製造者、標準制定者、網頁製造者和其他想參與其中的人所討論而得的，而多數成功的標準都是 retro-specs （實作、制定標準同時，甚至先實作），有些人認為標準應該保持純潔，不要受到瀏覽器製造者或網頁製造者的影響，這完全是錯誤的。」HTML 5 也是一個 retro-specs ，新功能都是跟著網路的變化所產生，像是 拖拉 API 、 近端儲存系統 等，最近還多了 device 標籤 和 stream API ，這些都是現在大家需要的功能，而目前只能用其他方法弄起來，像是拖拉要去算位置、範圍，近端儲存要裝像 Google Gears 的外掛，要抓 webcam 畫面或是撥影片則要用 Flash 或是 Java，未來這些功能都會變成瀏覽器原生支援，甚至用顯示卡 加速畫 3D 圖形 都不是問題。

另外可以拿來作反例的我覺得是 XML Schema ，整個複雜過頭，還有難解的用詞，據之前修課時的老師說是語言學家制定的，結果造成沒有工具很難寫，就算寫了沒驗證過我看也不敢拿來用。

今天下午在尋找能讓 Vim 的 Regular Expression 變得好看一點的方法，因為實在太多斜線了，當然直接就把目標鎖定在 perl 的語法，一開始找到一個 vim tip 有建議用 perldo ，不過編譯時要把 +perl 弄起來，使用上也不是很好用，而且不能搜尋，只能做取代，雖然 有人寫了 function 來搜尋，不過實際測試之後離方便使用還有些距離。 c9s 還有建議我用 very magic 看看，結果還是不夠滿意，後來換成找日本那邊，終於找到 eregex.vim 這個 plugin ，他的作法是把 perl/ruby 的 regexp 語法用 function 轉成 vim 的 regexp 語法，所以問題少很多，預設會把 S（大寫S）替換成用 perl/ruby 的 regexp 語法來搜尋搜尋取代的指令，使用方法和原來 s（小寫S）的都一樣，另外單純搜尋的部分有 :M/ 這個命令，也可以 map 到原來的 / 上：

nnoremap / :M/

使用上就和原來幾乎完全一樣了，超棒的～

順帶一提， Ubuntu 上要編譯出 +perl 的功能要 確定一下 libperl.so 在不在 ，像我的系統就只有 libperl.so.5.8，還要自己做個鏈結。