沒穿方服

Visual mode * 尋找多行文字

2011-12-24T17:51:00.000+08:00

PTT Editor 板看到的問題：如何搜尋多行文字？能不能 Visual 選起來搜尋？

以前從 kana 的 vimrc 看到一個自訂函數 search_the_selected_text_literaly('n')，這個設計是在 Visual mode 打 * 便能尋找選取的文字。

剛剛發現，處理一下換行字元就能支援多行 pattern 了，具體為 substitute(pattern, '\V\n', '\\n', 'g')。

成品

" Ref: kana - https://github.com/kana/config
vnoremap * :<C-U>set hlsearch<CR>:call <SID>search_selected_text_literaly('n')<CR>
vnoremap # :<C-U>set hlsearch<CR>:call <SID>search_selected_text_literaly('N')<CR>

function! s:search_selected_text_literaly(search_command)
  call SaveReg('0')
  call SaveReg('"')

  normal! gvy
  let pattern = escape(@0, '\')
  let pattern = substitute(pattern, '\V\n', '\\n', 'g')
  let @/ = pattern
  call histadd('/', '\V' . pattern)
  execute 'normal!' a:search_command
  let v:searchforward = a:search_command ==# 'n'

  call RestoreReg('0')
  call RestoreReg('"')
endfunction

註：SaveReg 和 RestoreReg 是用來備份 register 的自訂函數，此處不重要，就不寫了。

利用 Dropbox 同步 git repository

2011-12-19T22:52:00.000+08:00

多台電腦 git repository 最簡單的同步方式，應該是把 .git 目錄放在 Dropbox 底下。

在 repository 直接編輯 .git/config，加進一個叫做 {dropbox} 的 remote，url 設成 Dropbox 下的目錄；
再配合該 remote 設定一個叫 {wip} 的 branch。（後面有範例）

然後 cd 到 {dropbox} 目錄，把剛設的 remote url 建立起來： git init --bare

日後只要在 {wip} branch 做 git pull、push 就都是對 Dropbox 動作了。

我在 GitHub fork 別人專案後，通常會建一個 [remote "dropbox"]，配合 [branch "wip"] 自己亂改。寫到一個段落再整理進 master，另外 upstream branch 則是用來跟原作者的進度。

常用 .git/config 樣板

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true

[remote "origin"]
  fetch = +refs/heads/*:refs/remotes/origin/*
  url = git@github.com:{ME}/{PROJECT}.git
[remote "upstream"]
  fetch = +refs/heads/*:refs/remotes/upstream/*
  url = git://github.com/{AUTHOR}/{PROJECT}.git
[remote "dropbox"]
  fetch = +refs/heads/*:refs/remotes/dropbox/*
  url = /home/bootleq/dropbox/repository/bare/{PROJECT}/

[branch "master"]
  remote = origin
  merge = refs/heads/master
[branch "upstream"]
  remote = upstream
  merge = refs/heads/master
[branch "wip"]
  remote = dropbox
  merge = refs/heads/wip


; vim: filetype=gitconfig

實用客語：耗漦（ㄏㄠㄒㄧㄠ）

2011-12-18T11:09:00.000+08:00

在爸爸公司發現一本「客語字典」，查到一個阿婆常用、我一直不會寫的詞。

耗漦（ㄏㄠㄒㄧㄠ）

使用時機跟「屁咧」差不多，大概也猜得到，應該是河洛話 de facto 寫法「豪洨」的那個詞。
但是這本字典只有兩個字「虛假」解釋，沒了。

國語典「漦」ㄌㄧˊ：龍或魚的唾液。龍所吐沫，龍之精氣也。

還是很好奇語源由來。
有不雅的意思嗎？
無法理解這兩個國字怎麼來的，所以書寫時，還是不敢用。

生活用法

相當實用，也許能取代「屁啦」。

「我講正經的，不是耗漦的哦。」——此處耗漦同「虛假」「騙人」。
「耗漦」——可表達不以為然，或用於鬥嘴時的串場，同「你耗漦」。
「耗耗漦漦」——耗漦的加強版。以加強版的直覺與便利性來看，這個詞比國語的好用。

語音樣本

以下是 2008 年發神經錄的，前三檔是我阿婆、最後一檔是我的聲音。

英漢字典查詢

2011-12-17T19:21:00.000+08:00

有了 mattn/wwwrenderer-vim 應該就能輕鬆「在 Vim 裡查字典」了吧？
這兩週諸事不順，寫了 3 個解法，只有一個堪用。

Google 字典下架

第一版的 function，採用行動版 Google 字典（桌面版 8 月就關了），快又聰明，還能翻譯整句。

12/7 寫完，12/8 這個字典就停止服務、沒有中文了。恨啊。

Dr.eye 回應速度慢（可能是我實作問題）

第二版的 function，改用 Dr.eye（譯典通）字典行動版。

因為不是每次都慢，所以寫完→使用時才正視問題。加入計時功能後，發現 query 常常要花上 10、甚至超過 30 秒，完全無法忍受。

明明 Firefox 開都蠻快的啊…… 總之我很灰心，不想查了。

必应词典

第三次，不想再直接改舊 function，那個沒結構的東西寫了新的就失去舊的，太心寒了。
這次投靠微軟的 Bing 字典（智能手机版）寫成 thinca/vim-ref 用的 source：

bootleq/vim-ref-bingzh - GitHub

成品還在不穩定階段，最近也無心重構，就是頂著用用。

擷圖

目前顯示格式大致如圖，隨著每天使用，還會大改。

簡繁轉換：OpenCC

「必应词典」這個服務只有簡體字，以致： 1) 繁體的詞查不到翻譯， 2) 簡體的內文，台灣人看得很累。
解法是嘗試用 OpenCC 轉換，只要能執行 opencc 就自動轉。
目前我自己在 Ubuntu 上使用順利，不過 Windows 上還沒搞定。

輔助設定：normal `K`

nnoremap <silent> K :call ref#jump('normal', 'bingzh')<CR>

按 K 就會查游標上的單字。目前 ref-bingzh 會自動把 CamelCase 或 under_score 拆開，只查其中一個字。

輔助設定：visual `K`

xnoremap <silent> K :call ref#jump('visual', 'bingzh')<CR>

在 visual mode 按 K 就會查選中的字。

輔助設定：`:k`

cnoreabbrev <expr> k ((getcmdtype() == ':' && getcmdpos() <= 2) ? 'Ref bingzh' : 'k')

打 :k<space> 會自動展開成 :Ref bingzh 方便輸入。
例如想查 foo 就打 :k<space>foo<Enter>。

『斑鳩』使用前記錄

2011-11-21T22:21:00.000+08:00

最好的遊戲

「心目中最好的遊戲」如果想不出答案，那就保留吧，不必降低高度。

十年前買了平時沒需求的雜誌「月刊アルカディア 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 的出生成長、飽和到沒落。作者所說的「幅」，專欄解釋是「多樣性」變得狹隘，我的話「生存空間」被壓縮也是同一件事。

因為「偏偏執著在這個議題」正是我需要的，所以很快被吸引，並準備推崇。

註 2：「還原」乃透過在雜誌揭露每句的發言角度與原意，遊戲中的台詞仍是隱晦、投射的。
註 3：這段很多文字來自原專欄，但不見得是原意（萬一我會錯意），請了解。

遊戲語言是最得心應手的母語

語言能力有障礙、說話在試誤，表達就沒有力道，意思錯了也未可知。

過場動畫很棒，開始操作卻帶來困惑、讓人質疑原始設計—— 這是作者懂動畫語言，卻不熟遊戲語言的例子；即使音樂、劇本、○○高明，又注重細節、隱藏要素豐富…… 我還是覺得他沒做對。

反之對語言愈能掌握，就能用愈精準的句子把話說透。

斑鳩作為硬派射擊遊戲，這方面的「正確」基本讓人放心，常被談及的設計「簡潔」我想延伸下去也是在追求這個正確。

70~90 的 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《射擊遊戲的歷史》中文字幕版。

其他疑問

目前想到的大概就這樣，其他可能要玩著才會發現。再記幾件好奇的事：

閃亮銀槍是不是比斑鳩更好？
斑鳩似乎有很固定的最佳攻略法，這樣好嗎？
Project-RS 原定第三作主題是「未來」，不過我看一、二所講的「輪迴」其實是差不多、而且暗喻不能突破的，開發者井内洋又已離開 TREASURE，關於未來的想法會不會根本沒出現過。

vim-gitdiffall - 爬 git diff 也要用 Vim

2011-10-19T22:57:00.000+08:00

把 git-diff 的差異開在 Vim 分頁裡，也可以指定要看的版本，用 Vim 查閱 commit 歷史。
→ bootleq/vim-gitdiffall - GitHub

gitdiffall 指令

在 zsh 呼叫 gitdiffall 這個指令（目前是用 ruby 寫的，需要系統能跑 ruby）

參數跟 git diff 大致一樣。

查看某個 commit 改的東西

想知道 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

在 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 運算子（!）後面不加空白的理由

2011-10-17T22:31:00.000+08:00

快速答案是「一元運算子」。

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 沒有錯，但眼前還是解決風格一致的問題先了。

cycle.vim - group 設定簡介

2011-10-16T21:51:00.000+08:00

Group 是什麼

cycle.vim 搜尋相關候選字時（例如目前是 true，應該要找到 false），會在一連串的 group 中查詢；每個 group 是由 items 和 options 組成，以下便是一個簡單 group：
{ 'items': ['true', 'false'], 'options': {} }
如果想讓 foo 變成 bar，增加一個 items 為 ['foo', 'bar'] 的 group 就可以了。

怎麼設定 group

使用中的 groups 會存在 cycle_groups 這個變數，可以用 :echo string(g:cycle_groups) 查看；但是這東西比較繁瑣，所以不建議直接修改它的值。

比較好的方式是在 .vimrc 定義 g:cycle_default_groups 這個變數， cycle.vim 啟動時會自動解析它，把需要的 group 都建好。

具體例子如下：

let g:cycle_default_groups = [
      \   [['true', 'false']],
      \   [['yes', 'no']],
      \   [['on', 'off']],
      \   [['+', '-']],
      \   [['>', '<']],
      \   [['"', "'"]],
      \   [['==', '!=']],
      \   [['0', '1']],
      \   [['and', 'or']],
      \   [['in', 'out']],
      \   [['up', 'down']],
      \   [['min', 'max']],
      \   [['get', 'set']],
      \   [['add', 'remove']],
      \   [['to', 'from']],
      \   [['read', 'write']],
      \   [['save', 'load', 'restore']],
      \   [['next', 'previous', 'prev']],
      \   [['only', 'except']],
      \   [['without', 'with']],
      \   [['exclude', 'include']],
      \   [['width', 'height']],
      \   [['asc', 'desc']],
      \   [['是', '否']],
      \   [['上', '下']],
      \   [['男', '女']],
      \   [['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday',
      \     'Friday', 'Saturday'], ['hard_case', {'name': 'Days'}]],
      \   [['{:}', '[:]', '(:)'], 'sub_pairs'],
      \   [['（:）', '「:」', '『:』'], 'sub_pairs'],
      \ ]

可以只為特定檔案類型設 group 嗎

cycle_groups 可以分成 global 和 buffer 兩個 scope（作用範圍）的版本，分別是 g:cycle_groups 和 b:cycle_groups 兩個變數。搜尋的時候會以 buffer 版為優先，你可以讓 "get" 在 html 類型的 buffer 中轉為 "post"，在其他類型 buffer 中則轉為 "set"。

設定方式是在 .vimrc 定義 g:cycle_default_groups_for_{filetype}，其中 {filetype} 表示想生效的檔案類型。
例如 html 專用的設定是：
let g:cycle_default_groups_for_html = [ ...（後略）

註：可以用 :echo string(b:cycle_groups) 檢查設定。

調整 group 行為

Group 的行為可以用 options 微調。目前（version 0.1.0）支援的選項如下：

name

名稱，目前沒什麼用，只有處理衝突時（在多個 group 都有搜尋到目標字時）會顯示一下。
match_case

搜尋候選字時，大小寫預設是不計的，所以 True、true 和 trUe 都會被 cycle，只要設定其中一個即可。
反之若要限制大小寫相符才 cycle，就要設定這個選項。
hard_case

預設情形會保留關鍵字的大小寫位置，也就是 true/false 互換時，True 會變成 False、tRUe 會變成 fALse。
這個選項可以停用此功能，互換時「若設定中是寫 fAlse，就一律換成 fAlse」。
sub_tag

如果開啟這個選項，cycle.vim 會搜尋成對的 xml 開啟／結束標籤，有的話就一起 cycle 掉。
例如 <EM>example</EM> 可以變成 <STRONG>example</STRONG>。
sub_paris

這個比較特別，它是 sub_pair、end_with 和 begin_with 三個選項的簡易寫法，具體請看 doc。（建議用 sub_pairs 即可）

以 [['（:）', '「:」'], 'sub_pairs'] 為例，各個 item 會由 ":" 拆開， （:） 會拆成 （ 和 ）， 「:」 會拆成 「 和 」。
cycle.vim 處理 "（" 時，會搜尋成對的 "）"，若有的話就一起 cycle，
例如 （請保密） 可以變成 「請保密」。

具體要怎麼設定選項（options）

設定 group 時，每個 group 的第一個參數是 items，之後就都是 options 了。
支援以下各種型式：

[['true', 'false']] - 沒有 options
[['true', 'false'], {'match_case': 1}] - 以 hash 型式指定 options
[['true', 'false'], 'match_case'] - options 可以是字串，cycle.vim 會把它轉成 hash，hash 的預設值依各個 option 而不同，此處 'match_case' 的預設值為 1
[['true', 'false'], 'match_case', {'name': 'BOOL', 'sub_tag': 1}, 'hard_case'] - 字串和 hash 混著用也沒關係

你說完了沒

這篇應可滿足一般使用，我自己用到的也差不多這樣了。
在 doc 裡一些比較深入、低階的操作也有介紹，需要的話可以參考看看。

清理 blogger 貼圖的冗碼（改版）

2011-09-20T23:05:00.000+08:00

Blogger 文章編輯器「上傳圖片」自動插入的 HTML 為：

<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-NcfksJtd0V0/Tnilmxq3e-I/AAAAAAAABQs/qUa6u-iZSdU/s1600/ocarina.png" imageanchor="1" style=""><img border="0" height="50" width="50" src="http://1.bp.blogspot.com/-NcfksJtd0V0/Tnilmxq3e-I/AAAAAAAABQs/qUa6u-iZSdU/s320/ocarina.png" /></a></div>

做了一支 bookmarklet 把它改成以下格式：

<a href="http://1.bp.blogspot.com/-NcfksJtd0V0/Tnilmxq3e-I/AAAAAAAABQs/qUa6u-iZSdU/s1600/ocarina.png"><img src="http://1.bp.blogspot.com/-NcfksJtd0V0/Tnilmxq3e-I/AAAAAAAABQs/qUa6u-iZSdU/s320/ocarina.png" alt="" /></a>

將 bookmarklet 加進書籤 → 清理 blogger 插入的圖片標籤
在文章編輯器的 HTML 模式執行就立刻取代，不保證原文的安全，請自己保重。

原始碼

var
  $textarea = document.getElementById('postingHtmlBox'),
  pattern = [
    '<div class="separator" style="clear: both; text-align: center;">\n',
    '<a href="(.+)"',
    ' imageanchor="1" style=".*"><img border="0" height=".+" width=".+" ',
    'src="(.+)" /></a></div>'
  ].join(''),
  re = new RegExp(pattern, 'g');

if ($textarea) {
  $textarea.value = $textarea.value.replace(re, function (str, p1, p2, p3) {
    return [
      '<a href="', p1, '">',
      '<img src="', p2, '" alt="" /></a>'
    ].join('');
  });
} else {
  alert('錯誤：找不到 textarea#postingHtmlBox。');
}

cycle.vim 簡易使用說明

2011-09-18T11:49:00.000+08:00

安裝

建議用 Vundle 裝 → Bundle 'bootleq/vim-cycle'。
不然就用老方法，把所有檔案放到 runtimepath（預設在 ~/.vim）即可。
檔案在 https://github.com/bootleq/vim-cycle

簡易設定

要特別做的只有「哪些字能 cycle」設定，否則預設的字很少。
把 doc 287-341 行的範例加進 vimrc，再視需要修改就可以了，應該很容易看懂。
進階選項再看 doc。

用途，例子

預設會加一個快速鍵 <Leader>a，其中 <Leader> 預設是 \ 所以實際是按 \a。
（註：用 a 是取 Advance、Add 的 a，類似預設的 CTRL-A 功能）

按 <Leader>a 會把目前游標上的字換成下一個，以下舉例說明；若有特別標示，表示游標位置。

true → false
true 會變 false，false 會變 true；光這樣就很方便了。
Yes → No
大小寫會自動保持。
+ → -
== → !=
可是 → 可否
特殊符號和中文都可以 cycle。
Sunday → Monday → Tuesday → Wednesday → Thursday → Friday → Saturday → Sunday
typo 的機率降低了。
Rails Metal → Thrash → Technical Death
即使游標在空白上，也能試著搜尋關鍵字。
$li.addClass('foo') → $li.removeClass('foo') - jQuery element Attributes
position: 'upperLeft' → position: 'upperRight' - MooTools Element.Position
:render_with_me → :render_without_me - Rails alias_method_chain
處理串在一起的字，實用性增加不少。
<em>example</em> → <strong>example</strong>
HTML 標籤的開始／關閉標記可以一起 cycle。
「例子」 → 『例子』 → （例子）
成對的關鍵字可以一起 cycle。
不過目前未支援頭尾相同的 pair，例如 "例子"。

另外在 <Leader>a 前可以加 [count]，例如 2\a 會 cycle 到第二個的候選， Monday 就會變成 Wednesday 而不是 Tuesday。

還有在 visual mode 也可以用 <Leader>a，這樣就不會自動搜尋關鍵字，而是直接用選取的字來 cycle，遇到混淆時可以試試。

Vim plugin - cycle 開發背景

2011-09-17T23:47:00.000+08:00

要怎麼把 Yes 換成 No？標準答案是 ciw 再輸入 "No"。

更快的方法是寫 script 處理，很久以前看到一篇 Toggling yes-no，把常用組合先定義好，只要一個鍵就能把 Yes 換成 No，再按一次就換回來，真是聰明啊～這方法我用了很久，當時改出來的設定如這個 gist。

因為覺得方便，又有蠻多地方想改善，所以打算寫成 plugin。
搜尋 toggle 才發現真多人寫過，不過似乎大同小異，除了 SwapIt.vim：

用 visual 選起來，就可以處理含空白的 some words（原本的實作方式辦不到）。
可以把 <H1>example</H1> 變成 <H2>example</H2>（一次換掉前後 tag）。
可以吃 omni-completion 的結果，所以不必額外設定，就知道 CSS display block 可以換成 inline、none 等等。
其它。

我比較同意 SwapIt 的設計，認定 swap 這個功能，用力加強它。
SwapIt 的問題是實作還未成熟，所以我也 fork 它準備貢獻。但是送第二個 pull request 前，覺得有點走不下去：

繼續改下去，細部的實作幾乎都不一樣。
重寫比重構簡單。
在使用者立場，我想像的 interface 是另一番面貌，向前相容顯得多餘。
我想全權處理所有問題。

另外對 SwapIt 這個名字也有點在意，至少我搜尋的時候就沒想到 swap 這關鍵字。
想起來最適合的字是 Cycle（因為是在一組字中循環，例如 top right bottom left），但是在 GitHub 一搜就發現已經有同名 plugin 了 ——zef/vim-cycle——很精簡，程式聰明漂亮，可惜作者太忙比較沒空更新。

結果我的 plugin 還是叫 cycle，這樣好嗎？

我把碰到的困難告訴兩位開發者 Michael Brown 和 Zef，他們都很開放，表示基本上不介意我這麼做（我想還是有點情緒干擾吧）；而雖然大家目標類似，但個人考量的點（有趣的是想法從 coding style 與用法設計就看得出來）還是不容易統合，變成一個專案。

這種情況下，我就先開發再說了，把手上的問題解決。

目前 0.1.0 版本已經是堪用階段： bootleq/vim-cycle - GitHub
之後會再寫一篇簡易使用說明。

提升 Vim script 的可讀性，語法規範建議

2011-09-11T15:28:00.002+08:00

最近在寫 plugin，對之前的 coding style（主要用在 vimrc）有些不同意了。
其中一些比較確定、通用的部分是關於可讀性的，整理如下：

不要用簡寫
在 modeline 寫明縮排規則
用 marker 手動折疊程式碼，建立 section
增加空行，分隔程式區塊
註解不應影響程式排版
串接多個項目時，拆成多行
適當使用 Dictionary (hash) 進行參數操作
其他相關但未規範的部分

不要用簡寫

指的是選項、指令名稱的簡寫，例如：

function! → fun!
setlocal textwidth=78 → setl tw=78
execute "normal! dd" → exe "norm! dd"

例子可能不夠極端（還是看得懂），但是已經失去字面上的意思（最簡單的可讀）了。

此外還有一致性的問題，完全一樣的意思卻不能預期用哪個敘述。
例如想找函數定義，直接搜尋 func! 卻找不到 function!，問題是什麼？其實不必問了，這完全是可以避免的問題。

總之除非有足夠理由（例如故意用 fun! 定義比較 funny 的函數），還是一律用完整寫法吧。

在 modeline 寫明縮排規則

縮排和可讀性的關係是，縮排亂掉的時候會很難讀。

首先要訂好自己的縮排規範，用空白還是 Tab、要空幾格，然後確實遵守。
再來要了解每個人的規則會不一樣：

你用 Tab 排好的版，別人打開還是可能亂掉。
別人編輯你的 script 後，可能也塞了不一致的縮排字元進去。

減輕問題的方式是在每個檔案加上 modeline：
例如一律用空白，確保排版不會被 Tab 弄亂
" vim: expandtab softtabstop=2 shiftwidth=2
如果還是偏好 Tab（也許為了減少字數）
" vim: noexpandtab tabstop=8 shiftwidth=8

附上我的基本 modeline 如下（寫在檔案最後一行）

" modeline {{{
" vim: expandtab softtabstop=2 shiftwidth=2 foldmethod=marker

用 marker 手動折疊程式碼，建立 section

在註解中使用 marker（預設是 {{{ 和 }}}）整理程式碼是很普遍的作法， script 稍大時幾乎都會用上，否則會覺得難爬。

對以下常見的 folding：

多個有關的函數，可以歸納為一個 section（註：和 Vim motion 的 section 無關），但是沒什麼好方法表示，於是加上註解「以下這段是做 XXX」，然後在結束的地方寫「XXX 做完了」。這整段就適合當作一個 fold
讓多次出現的語法單位（通常就是函數）可以各自折疊

規範一個通用的格式。

以下是我的例子。從 Utils: 開始是一個叫做 Utils 的 section，用大寫字和冒號形成一個 vimCommentTitle（來自預設的 syntax 上色），又更顯目一點。

" Utils: {{{

function! s:save_reg(name) "{{{
  let s:save_reg = [getreg(a:name), getregtype(a:name)]
endfunction "}}}

function! s:restore_reg(name) "{{{
  if exists('s:save_reg')
    call setreg(a:name, s:save_reg[0], s:save_reg[1])
  endif
endfunction "}}}

" }}} Utils

折起來（一層）後，擷圖如下

增加空行，分隔程式區塊

函數之間，空 2 行。
因為函數中本來就經常會空 1 行，所以要空超過 1 行才清楚。
section 之間，空 2 行。
這裡 2 行就夠了，因為 marker（在註解中）和程式之間也有空行，所以不算註解的話，實際上 section 之間會空 6 行。

全部縮起來（`zM`）時，看見所有 section

打開一個 section，看見所有 function

抱歉擷圖是舊程式，函數之間只空 1 行，應該空 2 行……

各個 function 之間空兩行

各個 section 之間空兩行，實際程式空了 6 行

註解不應影響程式排版

手動 fold 有很多層的時候，我曾經把深層的程式加一級縮排：

" MAPPINGS             {{{1 ==================================================

  let maplocalleader = ","
  noremap  <Leader><LocalLeader> <LocalLeader>

  "   各種移動    {{{2

    noremap <expr> <Space>  repeat('<ScrollWheelDown>', 2)

看起來似乎更清楚，但這個超過註解該做的事了。
理想上要專注於程式本身的表達能力才對。

串接多個項目時，拆成多行

寫下 aaa, bbb, ccc, ... 這樣的敘述時，除非真的很簡單，否則不要擠在同一行，難讀又難改。

參數很多時
定義複雜的 List (Array) 或 Dictionary (Hash) 時

請用 backslash (\) 拆開。

call setline(
      \   a:before.line,
      \   substitute(
      \     getline(a:before.line),
      \     '\%' . a:before.col . 'c' . s:escape_pattern(a:before.text),
      \     s:escape_sub_expr(a:after.text),
      \     ''
      \   )
      \ )

這裡的縮排比較詭異，不是由 indent 選項而是由一個變數控制，見 ft-vim-indent，預設是 shiftwidth 的三倍。
let g:vim_indent_cont = &shiftwidth * 3
我沒有設這個變數，backslash 之後的縮排也是手動做的，規則是至少空一格，其餘每一層就縮一級。
單純是「採用預設值」這個考量。

適當使用 Dictionary (hash) 進行參數操作

可以考慮多用 hash（Vim 裡面叫 Dictionary）作為函數的參數，例如原本是：
function Img(src, alt, size, class) 或接受任意個參數的
function Img(src, alt, size, ...) 都可以改成
function Img(src, options)
就不必記參數的順序，或再解析 a:0、a:1（額外的參數會被轉成 a:N）了。

存取 options 的時候，盡量用點（.）取代方括號（[]），
例如 options.size 就比 options['size'] 簡單明瞭。

不過因為 Vim script 的特性，也有一些像陷阱的東西。
例如取值的時候要用 get(options, 'size') 比較安全，沒有 'size' 這個 key 的時候才會回 0，而不是報錯。
還有在 value 不是 Number 時，直接 if get(options, 'key') 會有型別轉換的細節要注意，通常會加一道 if type(get(options, 'key')) == type(xxx) 檢查，比較麻煩。

其他相關但未規範的部分

單行的長度

要填滿整行的話，會用 textwidth=78，和 Vim doc 一樣。
但是程式內文就不必了，因為怕太長其實是硬體問題，我認為不用管它，也解決不了它。
變數命名

Vim 對變數名稱有一些意見，例如 user function 第一個字要大寫，大小寫變數存進 session 時的規則也不同。
原則上使用 underscore_names 安全又簡單，可惜有時候必須大寫，還是會破例。

具體用字則是愈短、愈直接愈好，scope、autoload 和 Dictionary 可以善加利用，
例如 s:width、su#do()、contribute.till_die。
key mapping 的記法

原則是和 Vim doc 一致，也就是用 <C-X> 而不用 <C-x>。
不過這樣會失去大小寫的區別。
Magic 的 regexp

Vim 的 regexp pattern 對哪些字元有特殊意義（需要跳脫）和別家解釋不太一樣，在 pattern 前加上 \v \m \M \V 又有不同解讀，在 plugin 或一些內建 function 裡還會一律視為 \m。

這個因應情境有很多變數，所以目前也沒有規範。

文字對齊 plugin - Alignta 使用方式

2011-08-20T11:05:00.000+08:00

對齊文字用的 plugin，以前我是用 Dr. Chip 的 Align.vim，現在換成 Alignta 了；雖然預設功能比較不豐富，但實在好懂多了。

目前 ver. 0.2.1 只有日本語的 doc，如果 help 打不開（E426），可能要先 :set notagbsearch。

SYNOPSIS of Alignta command (for v. 0.2.1, UNOFFICIAL)

                              (Shifting
                               Alignment)
                                 <- 
                                 -> 
                                 <--
                                 -->

:[range]Alignta[!] [filter]  [align method][margin]   [-p] pattern[{count}] [pattern2 ...]

                   g/pattern  (Padding                              number
                   v/pattern   Alignment)                            '+'
                                  <           n:n                
                                  |        [0-9][0-9]
                                  >          [0-9]
                                  =          
                              (repeat as     @margin
                                LM[R]...)

!

有 ! 的話，pattern 會被解釋為 regexp。
filter

指定忽略哪些特殊的行（通常是註解）不進行對齊。g/pattern 只處理符合的行；v/pattern 不處理符合的行。
align method

Alignta 的對齊分為 Shifting Alignment 和 Padding Alignment 兩種。
align method 參數也分為兩套，區別是哪一套的同時，也用來指定對齊細節。

Shifting Alignment 比較簡單，只是將 pattern 的開頭垂直排在一起。
<- 是將每一行符合的部分，對齊到其中最靠左的 column；-> 則是對齊到最靠右的 column。
兩個 dash 的版本（例如 -->）表示使用 tab 字元排版。

另一種 Padding Alignment 是依 patten 將文字拆成多個欄位。
以 {L}{M}{R} 為一個單位，{M} 就是 pattern 符合的欄，{L}{R} 是它的左右側。可以用 <、|、>、= 指定各欄位靠左、靠中、靠右或保持原本方式對齊。
註：{R} 可省略，表示跟 {L} 相同，例如 :Alignta <|> = 讓等號兩邊靠外對齊。
註：若後面有指定多個 pattern，這裡可以重覆 {L}{M}{R} 來指定多個對齊方式。
margin

指定各欄位的間隔。
一般是配合 align metohd，有幾個欄位就寫幾個 margin，各個 margin 以冒號分開，例如 :Alignta <<3:1 =。
也可簡寫為 {L-margin}{R-margin} 或 {LR-margin}，但 margin 必須是個位數（ 0-9，10 就不行了），例如 46 即 4:6，4 即 4:4。
若沒有 align method，只想設 margin 時，在前面加 @ 即可，例如 :Alignta @00 =。
-p

如果後面的 pattern 是特殊字，加上 -p 可確保它被視為 pattern。例如 :Alignta -p << 是以 << 作為 pattern。
pattern[{count}]

pattern 指定要用什麼來對齊。
如果有設定 alignta_default_arguments 變數，那這個也能省略。

pattern 後面可以加 {count}，指定要符合幾次，超過 count 就不會再對齊了。
例如 :Alignta ={2} 只會處理前兩個等號，之後的就保持原狀。
另 {+} 表示有 pattern 符合時才對齊，否則不理它。

count 的預設值在 Shifting Alignment 是 {1}，Padding Alignment 是 {+}。
pattern2 ...

支援複數的 pattern，直接寫在後面。例如 :Alignta = /* */。
:Align

如果沒裝 Align.vim，那 :Align 就是 :Alignta 的別名，直接用 :Align 也 OK。

Help 檔案中，將 keyword 對齊到右端

2011-08-16T23:57:00.000+08:00

Help 檔案中，超連結的寫法是用兩個星號圍起來，例如：

*starting.txt*  For Vim version 7.3.  Last change: 2010 Sep 18

                                        *bold* *underline* *undercurl*
                                        *inverse* *italic* *standout*
term={attr-list}                        *attr-list* *highlight-term* *E418*

                                                        *right-justify*

PREVENTING LOADING                                              *netrw-noload*

如果是寫在行尾的，我就每次看了都想把它靠右對齊……

目前應該是沒這規範，看過的 help 也沒特別處理；總之我寫了一個 function 來做這件事；
只支援單行、只處理最後一個 *entry*，超過 'textwidth' 的也不管：

Right justify *keyword* in Vim help files. — Gist

使用前（'textwidth' 為 78，游標在 CONFIGURATION 那一行）

==============================================================================
CONFIGURATION                         *gsession-configuration*

使用後

==============================================================================
CONFIGURATION                                         *gsession-configuration*

可以在 filetype 為 help 時定義這個 key mapping

nnoremap <silent> <buffer> <LocalLeader>= :call HelpHyperTextEntryJustify()<Enter>

修改 ShowMarks.vim 於 Vim7 的不相容

2011-08-14T10:30:00.001+08:00

原版的 ShowMarks 在 2004 後就沒更新了，在 Vim7 使用會有一些問題。我聯絡不上作者，又 script 授權是 public domain，於是直接開個版本來維護：

bootleq/ShowMarks - GitHub

其中幾個修改參考了 vi/vim使用进阶: 指随意动，移动如飞 (二) – 易水博客的 patch。

主要問題與修改

key mapping
※如果你有舊版，可以下 :verbose map <Leader>m 檢視它定義的 5 個 mapping，另有 \sm 和 m 也是。
commit:a7d7d62 首先要改的是 map => nmap，以免在 Visual mode 或 Select mode（例如 snipMate 停著等輸入時就是 Select mode）按 m 變成 ShowMarks 操作導致錯誤。
再來增加了停用預設 mapping 的選項和 <Plug>ShowMarksOn 這樣的 mapping（讓使用者用 map mo <Plug>ShowMarksOn 自訂按鍵），應該是 plugin 預設 map 的最佳作法。 commit:72727b 另外原版用到 \sm 來轉接 m 指令（以便按下 m 時，除了原本 m 要做的事，還要 call 別的函數），這裡利用 :normal! 不會被 remap 的特性取代，也把它拿掉了。
「刪除 mark」的實作
commit:7ad76a
單純是 Vim7 的新功能 :delmarks。
舊版 :ShowMarksClearMark 作法是把 mark 都移到第 0 行，幾乎是不堪用的。
判斷 mark 所在行數
commit:6e087f4
Vim 6/7 處理 line("'g")（取 g mark 的行數）時，若 mark 在別的 buffer 就會有不一致結果。
單純改用 getpos("'g") 來判斷。
放棄 Vim 6 以下的支援
掰掰。

用 0 作為 EasyMotion 的 leader key

2011-08-13T17:14:00.002+08:00

先推薦一下 EasyMotion

這幾天試用的 EasyMotion 某些場合下確實能增加編輯速度。雖然使用頻率不高，但暫時也不會移除。

打從開始學 Vim 我就一向不相信「鍵盤比較快，請把滑鼠忘了」這種說法（現在也是）。
有時為了移動到某個位置，會進行很多無謂 motion，當按了大概 6 個鍵還到不了目標時，就會懊惱哦、我好慢！
目前感覺 EasyMotion 有打到這個問題，所以會繼續裝著、繼續驗證。

很難決定要設什麼 key

預設是用 <Leader>（\）開頭，配上 motion 指令就會發動，例如 \w、\f、\j。
顯然 <Leader> 太容易跟別人相衝，plugin 也提供了方便把 leader 鍵換掉的選項，
但是要換哪個 key 還是很難決定。

ZeroMotion

最後想法是用 0 當 leader 鍵，語義上是把 motion 前的 {count} 變成 0，
沒人知道 count 時，終極狀況就是沒有 count，不過 count 預設是 1，所以我只好下 0。
多少也呼應原設計：

It takes the <number> out of <number>w or <number>f{char} by highlighting all possible choices and allowing you to press one key to jump directly to the target.

0 不會太難按，平常也不會使用 0w、0j（沒有這樣的 count），所以不易衝突。
缺點是把原本的 0（跳到第一個字）指令蓋掉了；
我是認為 0 幾乎用不到，通常 <Home> 或 ^ 就夠了，所以直接放棄。

map 的左手邊不一定是按鍵

2011-08-11T21:55:00.006+08:00

map 指令的 {lhs} 可以不是用來 key 的。
這個用法至少在 2007 就被分享過（Vim: <Space>で始まるkey mappingの可視化 - while ("im automaton");）不過我是前陣子才知道的，sorry。

原本以為 map 就是 map 一個鍵，例如 map <C-S> :update<CR>；
或 map 一串 key sequence 如 map jk zz。

其實可以在 {lhs} 放抽象的 key sequence，例如以下 unite.vim 設定例片段：

nnoremap [unite] <Nop>
nmap f [unite]

nnoremap <silent> [unite]c :<C-u>UniteWithCurrentDir -buffer-name=files buffer file_mru bookmark file<CR>
nnoremap <silent> [unite]b :<C-u>UniteWithBufferDir -buffer-name=files -prompt=%\ buffer file_mru bookmark file<CR>
nnoremap <silent> [unite]r :<C-u>Unite -buffer-name=register register<CR>
nnoremap <silent> [unite]o :<C-u>Unite outline<CR>

定義了 [unite] 來取代 f，這樣就可以寫 [unite]c，使用時卻是按 fc。有幾個好處：
1) 更好讀。
2) 不想用 f 要換掉時，只要改一個地方即可。
3) 按下 f 時，畫面下方會顯示 [fuf]（如果沒把 'showcmd' 關掉的話），相當有意義。

再舉這幾天試用的 EasyMotion 設定為例：

noremap [emotion] <Nop>
noremap [emotion]<Space> f
map f [emotion]
let g:EasyMotion_leader_key = '[emotion]'

把 [emotion] 拿來當 EasyMotion 的啟動鍵，實際上是 f。
想用原本的 f 時，就按 f<Space>。

此外在 plugin 中常看到這樣的寫法（取自 rails.vim）：

nnoremap <buffer> <silent> <Plug>RailsAlternate  :<C-U>A<CR>
nnoremap <buffer> <silent> <Plug>RailsRelated    :<C-U>R<CR>
nnoremap <buffer> <silent> <Plug>RailsFind       :<C-U>REfind<CR>

其中 nnoremap <Plug>RailsFind 看起來跟這篇道理很像，可以方便用 map <Plug>RailsFind 來定義 plugin 的 map。不過 <Plug> 其實是 map 的一個保留字 <Plug>，把 <Plug>foo 放 {rhs} 時 'showcmd' 顯示也怪怪的；所以雖然可以用，還是先在 plugin 裡用就好了。

試試新的萬能尋找器 unite.vim

2011-07-06T23:24:00.000+08:00

UNITE ALL SOURCES

為了寫這篇，還特地試了一下 Command-T 這個搜尋工具，它找的 source 是「檔案」。

Command-T 快速找到檔案，輸入框在圖片下方

而我慣用的 FuzzyFinder 則是能找更多東西，例如之前寫過找 register 和分頁；執行的動作也不一定是「開啟」，可以是貼上、跳過去或其他。
加這些 script 時難免會想「不管什麼東西，只要能找的都交給 FuzzyFinder 吧」。

在另一個 plugin: ku 裡這些「能找的東西」被進一步定義為 source。
ku 在自訂 source 和相應的動作上有更完整的設計，而不是有「本來是用來找 file」的味道。

ku 找檔案的樣子

按了 `<Tab>` 可以選 action，預設 mapping 跟 unite.vim 大致一樣

最近才發現一個新的，Shougo 寫的 unite.vim，因為看到高手的設定檔換上了，就來試試。

不依靠 completion 介面

Unite.vim 第一個明顯特色是打開尋找 window 後，彈出選項的介面不是 Vim 的 completion 功能（按 <C-X><C-P> 彈出來的那種），而是自己在 buffer 裡畫出來的。
這表示可以進入 normal mode 改你的關鍵字，plugin 也更有機會對選項動手腳，畢竟 completion 原本用在 insert mode，確實限制較多。

左邊 split 的視窗就是 unite，大得嚇人（預設是水平 split 在上方，但還是很高）
這裡可以「多選」，以前是做不到的。

當然也有模糊搜尋，例如輸入 **/*re 7 !2 縮小搜尋結果

Buffer 裡面可以亂搞，例如可以進 visual mode 多選

依照 source 的 kind 選擇能用的動作，概念跟 ku 差不多

好多好用的 source

Register、分頁都是預設就有了，doc 裡還有一堆，讀完還可以看 github wiki 上的 unite plugins，經常有新的 source 真是強大到令人生氣。
而且沒有限制一次只能找一種 source，例如 :Unite file buffer file_mru 會把檔案、buffer 和最近開的檔案放一起給你選。

找 register

把 `/` 搜尋的結果當成 source，也是預設功能

把任意命令的輸出當成 source，例加下面是 `:Unite output:version`，這也是預設功能

結論

兩個問題 1) 開出來的 window 太大，好醜 2) 目前還是太常遇到 error
主要是問題 1 好像無解，所以我要繼續用 FuzzyFinder…… 不然其實解這些 error 也很有啟發性。
至於 ku 試了一下好像速度比較慢（可能 cache 沒設好？）文件也不是很全，有點疑惑為什麼不沿續開發 FuzzyFinder 就好。

按方向鍵的左，變成這樣，應該是鍵盤送出 `^[OD` 的關係吧

輸入關鍵字時也可以按 `<C-J>` 切換選項，可是這時還在 insert mode，不小心會按到插字

分享我的 Vim 設定 - vimrc_human

2011-06-19T21:11:00.004+08:00

一邊喝飲料一邊讀別人的 vimrc 真是很棒的休閒活動。
我也想分享 vimrc 提供社群讀物。

於是建了一個 vimrc_human，內容就是我的 vimrc 加上詳細註解（現在第一個 commit，都還沒加……），但也因為如此，它很難是我的最新設定。

bootleq/vimrc_human - GitHub

另一特徵是用 Vundle 管理 plugin、colorscheme 等擴充功能（沒聽過，可參考 Vundle, Bundler for Vim : O3noBLOG 簡介），Vundle 加上一些對 runtimepath 的處理，可以把整個環境裝到 /tmp/ 目錄下，避免跟原本的 ~/.vim 相衝（利用 rtp-=~/.vim，但 plugin 仍可能用到 ~/.vim 就是），讓「裝來玩玩」這件事變簡單了。
具體請參考 github 上的 README。

註：

目前不支援 Windows 上的 gVim。我自己用 Cygwin + gVim 是還可以。
「裝來玩」這件事是有安全性疑慮的，畢竟 vim script 神通廣大，請自己小心。

用 Noise 偵測網頁內出現了關鍵字

2011-03-27T13:30:00.000+08:00

收到使用者對 Noise 的問題

為了等待某個詞的出現，我讓一個討論區，請一個外掛，不停地、不停地重讀。
假如能夠 find 到那個詞時，發出聲音通知我，

我就可以同時做別的事了。

解決辦法，在 Noise 設定這個聲音

DOMContentLoaded&gBrowser.contentWindow.find('WORD_I_CARE')

（事件類型是 window event）

每次 DOM 讀完後，便自動進行尋找（Ctrl + F），若有找到就發出聲音。

實際上要加入網址限制，免得每個網站都自動尋找：

DOMContentLoaded&(event.target.location.host==='www.forum.com'&&gBrowser.contentWindow.find('WORD_I_CARE'))

除了 host，也有其他屬性可用來設限制，參考 window.location (#properties) - MDC Doc Center。

這幾個月使用中的 JSLint + Vim 搭配方案

2010-12-25T16:09:00.002+08:00

寫個 script 在 shell 透過 rhino.jar 跑 fulljslint.js，在 Vim 也寫個 function 呼叫它，於是可以用 quickfix window 除錯。

在 Windows 上沒用。
不使用 jslint.vim。雖然跨系統、放 jslintrc 設定檔等作法很棒，但是 1) 即時檢查和 highlight 標錯的顯示方式都不是我要的，甚至有點惱人。 2) 想試試直接用大師寫的 fulljslint.js，在 Vim 以外的地方可能也較好整合。
不使用 javaScriptLint.vim，因為 JavaScript Lint 不是 JSLint 啊，跟這主題無關。
使用 Rhino 當 JavaScript engine，因為最好裝。
不過它的 JavaScript 版本只實作到 1.7（Firefox 2 的程度）所以像 JSON 就不能直接吃，要多 include 個 JSON2.js。
具體用到的檔案：
- ~/bin/jslint （唯一實際被叫的指令，內容主要是 java -cp rhino.jar …）
- ~/scripts/fulljslint.js （即 Douglas Crockford 的 fulljslint.js）
- ~/scripts/jslint.js （由官網的 rhino.js（現已移除）修改而來，連接 fulljslint 和 rhino）
- ~/scripts/json2.js
- ~/scripts/rhino.jar
修改錯誤訊息的格式，改成跟 closure compiler 相似，就不必再調 Vim 的 errorformat。
目前 JSLint 用的預設 option 直接寫在呼叫 fulljslint.js 用的 script（jslint.js）裡。
在 shell 中呼叫的指令是 jslint file.js '{"extraOptionKey":value}'。 extraOption 可以用來蓋掉預設選項。
在 Vim 中呼叫的指令是 :JSLint。

取得檔案

fulljslint.js - douglascrockford/JSLint - GitHub
json2.js - douglascrockford/JSON-js - GitHub
rhino.jar - Download Rhino - MDC Doc Center （即 rhino1_7R2.zip 裡的 js.jar）
bin/jslint、scripts/jslint.js 和 vimrc 設定例 - gist: 754754 - Using JSLint command within Vim.- GitHub
以上 js 檔案皆沒壓縮，實際使用前我會先讓 closure-complier 壓一下。

工作滿一年

2010-12-24T23:49:00.001+08:00

還經常冒出剛找到工作的爽爽心情
- 回家在公車上會忍不住偷笑。（不過可以搭公車的這間倒了……）
- 從洗手間走回辦公室也莫名地樂。
- 應該是同事都很夢幻的緣故。
剛開始還覺得上班跟自己在家做的事差不多，就是有錢拿

久了技術有進步，不過作品都不能表達自己，這麼說也就沒什麼了不起的事。
所以不上班也可能更好。

某些場合還是會發現自己的缺點

以前發現的、不能改的就當作人格特質，所以年紀到了就不該有新的缺點才是。
這時發現技術不能解決的問題就毀了。

此外未滿七個月就拿不到失業救濟金這回事，也是難得的爛經驗。

Vim 類似其他編輯器「書籤」的功能（使用 ShowMarks + wokmarks）

2010-12-12T20:35:00.000+08:00

在沒有規則的位置間移動

雖然 ``、ga 等跳轉指令有不少，但是要跳到沒特殊意義的位置——例如「剛剛有看到，不過具體看到什麼完全沒印象」——這種情形除了 mark 應該也沒有更好的解了。

於是用 ma、mb、……放了幾個 mark，結果更難用：

視覺上看不見哪兒有 mark，所以不知道某 mark 的位置，比方 `b 會跳到哪裡去。
事實上按了 ` 之後，就會卡在不知道要按哪個字母。
不知道哪些 mark 已經用過，例如下 md 的時候要擔心會不會蓋掉舊的。
事實上按了 m 之後，就會卡在不知道要按哪個字母。

ShowMarks plugin

ShowMarks 會利用 sign column（在行號左邊的一欄，預設不會有）顯示 mark 的位置。雖然是很老的 plugin，不過先進替代品從缺，功能也冇問題，就用吧。

唯一不滿是用了 CursorHold autocmd 在閒置時自動開啟（如果開啟檔案後，突然畫面左邊冒出一條 bar，就是這功能），所以 fork 一份 bootleq/ShowMarks，加上 let g:showmarks_auto_toggle=0 即關閉它。

wokmarks.vim plugin

wokmarks.vim 提供不必記憶 mark 名稱（例：a-z）的操作。指令會變成 Prev、Next、Set、Toggle、Kill 這樣的感覺；另外設置 mark、在 mark 間移動時也會在狀態列顯示訊息。

具體設定

gist: 738007 - [vimrc] ShowMarks and wokmarks.vim- GitHub

完成後，看到有感覺的行就按 mm 放標記（sign column 會自動開啟），覺得這行沒用就按 mm 取消標記，想瀏覽標過的地方就按 mj、mk 前後移動。若新開的檔案沒有顯示任何標記，就按 mo 或 mt 顯示。

限制

因為使用 Vim 本身的 mark，所以 mark 總數有限（a-zA-Z，其中大寫的又不適合單一檔案使用）。

如果真的需要 26 個以上，也有一些 plugin 會另行記錄標記資訊，不過「不用 Vim 的 mark」是否比較好，就要考慮一下了。

將複數 git diff 以 vim 分頁一次開啟

2010-09-11T19:54:00.001+08:00

煩惱許久的需求—— git difftool, open all diff files immediately, not in serial - Stack Overflow。具體狀況是：用 git-difftool 呼叫 vimdiff 看變更，會重複「2 files to edit ～自動進入 Vim 比較一個檔案～手動離開 Vim」這個流程，有 10 個（變更的）檔案就會重複 10 次，而且中間不知道怎麼停下來……

原文的解法我沒試成功，而是靠之前寫的 function，加上在 .zshrc 裡設定：

alias gitdiffall='vim -p `git diff --name-only` -c "tabdo GitDiff" -c "tabfirst"'

之後只要輸入指令 gitdiffall 即可。

直接在 Vim 內與 git 舊版檔案 diff

2010-08-31T14:42:00.000+08:00

檔案改到一半發現自己失憶，忘記改了哪些東西，只好跟上次 git push 的狀態比較看看了。

正統作法是在 shell 下指令 git diff，或下 git difftool 用 vimdiff 分割視窗顯示，如下圖，前者在檔案多時容易快速概觀，但單一檔案時還是 vimdiff 方便。

目前看到兩個插件 hypergit、vcscommand 都可以在 Vim 裡直接顯示 diff 結果，前者是 git-diff 型式，後者是 vimdiff 型式（取出舊版內容，再切割視窗作 vimdiff）。我的需求比較接近後者，但又不想裝整支 vcscommand，於是擅自取出原始碼，改寫進 vimrc。

用到的 git 指令

git rev-parse --show-prefix
若指令來自 git 的子目錄，輸出該目錄對 .git 的相對路徑。
git log -1 --format=format:%s\ %n%h' -- '%an' -- '%ai\ '('%ar') HEAD
顯示 HEAD 所在的一條 log，輸出格式為 [主題] \n[hash 縮寫] -- [作者] -- [日期] ([相對日期])，
例如 fefe3c8 -- bootleq -- 2010-08-30 18:14:37 +0800 (13 hours ago)
git show HEAD:some_path/some_file
顯示 HEAD 中 some_file 的檔案內容。

原始碼

gist: 558647 - [.vimrc] git diff.

功能說明

GitDiff 指令
輸入 :GitDiff 即可切割視窗顯示目前檔案的 HEAD 版本，可加一個參數指定更早的 HEAD，例如 :GitDiff 99 取得 HEAD~99 版本。顯示後會進入 diff 模式。另外可用 echo t:git_diff_info 顯示該 commit 的簡易資訊。

註：指令取的 HEAD~ 並無限制「有變更當前檔案」所以可能往前跳好幾個 HEAD 也看不出變化。
MyDiffOff 指令
因為預設的 :diffoff 指令可能會把本來的 foldmethod 等 diff 相關選項蓋掉，所以改用 :MyDiffOff 來關閉 diff。
不過也只是設回我的預設值，沒有真的建立暫存／重設機制。
GitDiffOff 指令
進入 :GitDiff 後，用 :GitDiffOff 快速恢復到原始狀態。（目前只支援從兩視窗的狀態復原）