在爸爸公司發現一本「客語字典」，查到一個阿婆常用、我一直不會寫的詞。
使用時機跟「屁咧」差不多，
大概也猜得到，應該是河洛話 de facto 寫法「豪洨」的那個詞。
但是這本字典只有兩個字「虛假」解釋，沒了。
國語典「漦」ㄌㄧˊ：
龍或魚的唾液。
龍所吐沫，龍之精氣也
。
相當實用，也許能取代「屁啦」。
以下是 2008 年發神經錄的，前三檔是我阿婆、最後一檔是我的聲音。
有了
mattn/wwwrenderer-vim
應該就能輕鬆「在 Vim 裡查字典」了吧？
這兩週諸事不順，寫了 3 個解法，只有一個堪用。
第一版的 function， 採用行動版 Google 字典（桌面版 8 月就關了），快又聰明，還能翻譯整句。
12/7 寫完，12/8 這個字典就停止服務、沒有中文了。 恨啊。
第二版的 function， 改用 Dr.eye（譯典通）字典行動版。
因為不是每次都慢，所以寫完→使用時才正視問題。 加入計時功能後，發現 query 常常要花上 10、甚至超過 30 秒，完全無法忍受。
明明 Firefox 開都蠻快的啊…… 總之我很灰心，不想查了。
第三次，不想再直接改舊 function，那個沒結構的東西寫了新的就失去舊的，太心寒了。
這次投靠微軟的
Bing 字典（智能手机版）
寫成
thinca/vim-ref 用的 source：
bootleq/vim-ref-bingzh - GitHub
成品還在不穩定階段，最近也無心重構，就是頂著用用。
目前顯示格式大致如圖，隨著每天使用，還會大改。
「必应词典」這個服務只有簡體字，以致： 1) 繁體的詞查不到翻譯， 2) 簡體的內文，台灣人看得很累。
解法是嘗試用 OpenCC 轉換，只要能執行 opencc 就自動轉。
目前我自己在 Ubuntu 上使用順利，不過 Windows 上還沒搞定。
nnoremap <silent> K :call ref#jump('normal', 'bingzh')<CR>
按 K 就會查游標上的單字。 目前 ref-bingzh 會自動把 CamelCase 或 under_score 拆開，只查其中一個字。
xnoremap <silent> K :call ref#jump('visual', 'bingzh')<CR>
在 visual mode 按 K 就會查選中的字。
cnoreabbrev <expr> k ((getcmdtype() == ':' && getcmdpos() <= 2) ? 'Ref bingzh' : 'k')
打 :k<space> 會自動展開成 :Ref bingzh 方便輸入。
例如想查 foo 就打 :k<space>foo<Enter>。
「心目中最好的遊戲」如果想不出答案，那就保留吧，不必降低高度。
十年前買了平時沒需求的雜誌「月刊アルカディア 2002 - 1 月号」，當期有 4 彩頁的『斑鳩 IKARUGA』遊戲介紹 + 開發者訪談，還有最震撼我的在後面——黑白頁的「Old Game Mesuem」專欄，題目是：
輪廻する世界 井内洋と『プロジェクトRS』
『斑鳩』を前にして、我々が知っておくべきこと。
內容簡介 Project-RS（註 1）相關事情，在 google jp 還挖得到整篇備份。
專欄只有 2 頁，我的日文也不好，還是讀得無比激動。
這個作品講的問題就是我的問題，想表達的東西準確配在遊戲裡，用強烈的演出釋放出來。
註 1：RS 指的是 Radiant Silvergun（閃亮銀槍），『斑鳩』原本是 RS 三部中的 2。關於銀槍的介紹，推薦一篇 Xbox Life - Xbox 360遊戲攻略‧情報- 傳說般的射擊遊戲再臨！《閃亮銀槍》遊戲介紹。
以下記錄「到目前為止」對斑鳩的觀感，因為
寫這篇的時候我才剛買 Xbox 360，準備買 XBLA 上的斑鳩而已，真的是一 coin 都沒投過。 這麼難得應該記錄一下使用前後的差別，也體驗看看「遊戲是否一定得用玩的」。
印象中的 gameplay 都是 Super Play，例如旁邊影片的 Chapter 1 或者 1 Player - 2 Player game，手上也有一片『斑鳩 APPRECIATE DVD』收錄高手的夢幻表現。
回到現實自己 STG 技術卻相當爛，也沒空練習，大概會玩得很艱辛…… 不過那就將來再提吧。
「只生產使用者吃過的東西，餵飽 Light User 還剩下什麼？」是我所知 Project-RS 的重要動機。 （註 3）
不限於 STG 主流退化為「射擊 + 炸彈」這件事，也不限於遊戲業，「滿足大眾需求」一直是娛樂界的常規工作。 雖然接受人各有選擇，但是生活被低俗充斥，還是讓我不堪其擾。
閃亮銀槍的世界設定，就是創作停滯的遊戲界的縮影。 一個明顯宣示是 SS 版最終戰的人聲訊息，可以還原（註 2）為開發者、商人、退出者……等立場的對話； 而故事描述的輪迴思想，也能套用在 STG 的出生成長、飽和到沒落。 作者所說的「幅」，專欄解釋是「多樣性」變得狹隘，我的話「生存空間」被壓縮也是同一件事。
因為「偏偏執著在這個議題」正是我需要的，所以很快被吸引，並準備推崇。
語言能力有障礙、說話在試誤，表達就沒有力道，意思錯了也未可知。
過場動畫很棒，開始操作卻帶來困惑、讓人質疑原始設計—— 這是作者懂動畫語言，卻不熟遊戲語言的例子； 即使音樂、劇本、○○高明，又注重細節、隱藏要素豐富…… 我還是覺得他沒做對。
反之對語言愈能掌握，就能用愈精準的句子把話說透。
斑鳩作為硬派射擊遊戲，這方面的「正確」基本讓人放心， 常被談及的設計「簡潔」我想延伸下去也是在追求這個正確。
有意地重現了 STG 發展以來的魅力要素，所以有人說閃亮銀槍是 STG 的集大成。 這件事之所以很酷，因為它是這個世代的創作者，為了講自己的問題而忠實做的反省。
從 1978 的『Space Invaders』（太空侵略者，TAITO）開始，除了確立基本的「射擊」「閃避」外，因為無法像現在一樣連發子彈，甚至用光束橫掃敵人，所以還能提取出單發瞄準的獨特「狙擊感」。 在斑鳩裡按住射擊鈕是自動連發的 double shot（一次射出兩發，範圍較廣），單按則是 single shot，搭配連續擊破同色敵人便會額外加分的 chain combo 系統，就是在重現這個樂趣。
Invader 框架的後繼者『Galaxian』（小蜜蜂，1979 / namco）和『GALAGA』（大蜜蜂，1981 / namco）在敵人行動模式等各方面有不少進步，但火力還是一樣陽春，要等子彈離開畫面才能再開砲。
接下來 Project-RS 相當重視的「地形」與「解謎性」初步出現在『Scramble』（1981 / KONAMI）開始的橫向捲軸遊戲中（註 4），因為視點能辨別高低差，自然發展出起伏的地勢，拓展了攻略想像。 地形不但造成射擊屏障，移動時也要小心不能撞山，或者畫面捲動時被山撞死。
註 4：其實美國 Williams 於 1980 年已有相似的遊戲 Defender，不過這邊就以偏日本的史觀將它略過。
縱向捲軸的 XEVIOUS（鐵板陣，1983 / namco）也值得一提，遊戲故事和世界觀、音樂等內容有了講究的製作（雖然遊戲本身只有音樂表現比較明顯），因此在整個遊戲史上有一定地位。 閃亮銀槍的細膩製作固然也受推崇，但這裡特別提的是遊戲中偷藏了不少其他作品的料，其中就包括 XEVIOUS 發明的「隱藏角色」（藏在地圖中，找到可以加分），某個出現位置更是仿得非常露骨。
1985 延續橫向射擊優點的『Gradius』（宇宙巡航艦，KONAMI）登場，地形造成的戰略意義和關卡特色變得相當強烈， 此外還多了重要的「機體強化」設計—— 自機收集道具後，可以自由「Power Up」提升速度、武器、option（子機）、護盾等能力。 對比閃亮銀槍也有多樣的武器系統和升級要素，斑鳩倒是轉為完全不做，機體始終一致。
之後 STG 持續鑽研深度，新鮮感降低，難度提升而更挑玩家，各種理由加上 1991 格鬥熱潮爆發，終於衰退去了。
跳到 1997『怒首領蜂』（CAVE）開始發展出一系列「彈幕遊戲」，超大量敵方子彈溢滿畫面，形成驚人的華麗彈幕，是一股遊戲樂趣由「射擊」往「閃避」方向變態的極端風潮。
閃亮銀槍（1998）和斑鳩（2001）都不算彈幕遊戲，但最後都是絕望的閃避關卡，於是輪迴的最後階段正是彈幕，不曉得是否巧合。
※關於射擊遊戲的歷史，可以參考記錄片 盒子內的時間 » GameOne《射擊遊戲的歷史》中文字幕版。
目前想到的大概就這樣，其他可能要玩著才會發現。再記幾件好奇的事：
把 git-diff 的差異開在 Vim 分頁裡，也可以指定要看的版本，用 Vim 查閱 commit 歷史。
→ bootleq/vim-gitdiffall - GitHub
在 zsh 呼叫 gitdiffall 這個指令（目前是用 ruby 寫的，需要系統能跑 ruby）
參數跟 git diff 大致一樣。
想知道 1836777 這個 commit 改了些什麼。
使用 gitdiffall @1836777，會比較 1836777 和它的前一個 commit。
註：前一個 commit 不一定是 1836777^，而是從 git log 取出的前一項，這是為了提供更線性的用法。
就會開在 Vim 裡面。
這時可以下 :GitDiffInfo logs（同 :GitDiffInfo 不加參數）看 git log。
但是在 diff 進行中，比較常用的可能是 :GitDiff（同 :GitDiffInfo log，注意參數是 log 不是 logs，後面會說明）。
看完請用 :GitDiffOff 來關閉 diff，確保幾件事：
1. 跳回編輯該檔案的目前版本。
2. 還原比較前的 diff 相關 option（Vim 內建的 :diffoff 會設回預設，不一定是原來的值）。
看完 1836777，想看下一個 commit，因為剛才有顯示 Shortcut for this commit is 7，所以只要 gitdiffall 6 就行了。
以下圖來說，gitdiffall 會打開兩個紅色的檔案；
gitdiffall --cached 會打開綠色的。
以前寫的將複數 git diff 以 vim 分頁一次開啟，現在可以用 gitdiffall 取代了。
在 Vim 裡面也可使用 :GitDiff，會比較目前檔案和它的某個版本，這時就不需要 ruby 了。
參數跟 gitdiffall 類似，也稍微支援自動完成。
Diff 中可以用 :GitDiffInfo 看比較範圍內「全部 commit」的 log，
加上參數 :GitDiffInfo log 可以看「最相關的一個 commit」的 log（跟前述「GitDiff 時再呼叫 :GitDiff」效果一樣）。
GitDiff 另外支援一個用法，就是 revision 的部分使用 +<n> 的型式，有別於 <n> 是找前一個 commit， +<n> 會找「包含目前檔案」的前一個 commit，可以避免 <n> 找不到變更的情況。
例如 :GitDiff +1。
快速答案是「一元運算子」。
NOT matter 要寫成 ! matter 還是 !matter 這個問題……
很長一段時間我是用前者，多個空白比較明顯，不會漏看驚歎號。
ruby 文件 not 運算子的範例，
! me 和 p(! false)
也有空白，我想就是求明顯、清楚。
Kohana framework 的 Conventions and Style 也有類似考量：
The ! (bang) character must have a space on either side to ensure maximum readability.
『! 的兩邊都必須有一個空白，以確保最大可讀性。』
註：這一章是講括弧用法，所以是說 if ( ! $foo) 和 if (!$foo) 的情況。
不過我發現別人的寫法，絕大部分都是不空白的 !matter 風格。
我已經沒印象上次看到 ! matter 是何時了。
我也到 PTT ruby 板問了一下。
沒有明確出處，但找到一些敘述，一般不空白的理由是「Unary operation（一元運算子）後面不加空白」。
就像 -4 不會寫成 - 4。
更精確地說是「一元運算子和它的運算元之間」不加空白。
就像這個 NetBeans 選項 Bug 135699 – Use option "space between unary operator and operand"。
最後在 Douglas Crockford 的 JS Code Conventions 看到更具體、可以照做的規範：
No space should separate a unary operator and its operand except when the operator is a word such as typeof.
『一元運算子和它的運算元之間，不該有空白，除非該運算子是一個 word，例如 typeof。』
其實我已經改用 !matter 一段時間了。
仍然懷疑 ! matter 沒有錯，但眼前還是解決風格一致的問題先了。
電梯向下