• git revert & git commit：這個方式很直覺，直接 revert 回上一個版本，然後重新 commit，不過因為 revert 會連這次 commit 中的記錄也消掉，這樣太麻煩了，我只是想改個 commit message 而已啊！XD
• git commit –amend：這個可以直接翻譯成”重新修改最近這次 commit”，其相當於
  

  $ git reset –soft HEAD^
  $ … do something else to come up with the right tree …
  $ git commit -c ORIG_HEAD

然而，對於要修改較舊的 commit，上面的做法可能就不適用了，據我所知目前的做法有兩種，第一種是使用 git rebase：

git rebase –interactive <after-this-commit-id>

這樣會跳出介面讓你選擇想要修改的 commit，選擇完畢後，會由舊到新依序停在每個你所選擇的 commit，然後利用

git commit –amend

來修改該次的 commit，再搭配

git rebase –continue

來繼續下一個選擇的 commit。這種做法很方便，也可以快速地達到目的，因為是用 rebase，修改 commit message 倒是還好，如果有修改到 content，可能就要注意一下 conflict & merge 的問題了。另外，這個方式對某個我試的結果，對於修改 first commit 會沒輒。這時候可能要使用另一種比較麻煩的做法了。

第二種做法是利用一個由要修改的 commit 產生一個 target commit (在另一個 branch 中)，同樣搭配 git commit –amend 來修改，最後利用 git rebase 來覆蓋原本的 commit：

# tag the source commit so we can reference it
git tag source-commit <source-commit-id>
# checkout on its own branch
git checkout -b fake-branch source-commit
# amend the commit
git commit –amend
# after you changed the commit message, checkout the original branch
git checkout <original-branch>
# and rebase it onto the source commit
git rebase –onto fake-branch source-commit
# then nuke the temporary branch and tag we created
git branch -d fake-branch
git tag -d source-commit

就看情形使用了，大部份還是用第一種做法，不過一開始就把 commit message 寫好最省事 XD

Error parsing the server “<server name>” “clients.xml” file.

and

The type initializer for ‘VirtualInfrastructure.Utils.HttpWebRequestProxy’ threw an exception.

After googling, I get some solution. With a little modification from Pank’s patch, it works fine now.

P.S. The newer version 2.0.50727.4927 of system.dll seems not work, so that’s why to pack version 2.0.50727.3053.

>>> import rlcompleter, readline
>>> readline.parse_and_bind('tab: complete')

這樣便可以使用 Tab Completion 的功能了，結果大致上會是：

>>> import os
>>> os.lis<TAB>
>>> os.listdir
>>> os.li<TAB><TAB>
os.linesep  os.link    os.listdir

雖然有了基本的 Tab Completion 功能，但說真的，還是挺不習慣 Python 原本的 Shell，後來都改用 IPython 了，比原本的 Python Shell 強大很多，重點是…它會自動 Indent，我不用再按<TAB>按到死了。

看了一下官網的說明，大部份的常用指令都有實作，而且一裝完介面瞬間感受得到有種 VIM-Style，官網還有 Tips & Tricks 專區，不過目前看來數量沒有很多，google 一下應該可以找到更多人的使用經驗，也有些人直接把設定放出來。

現在正在探索它的設定，畢竟跟原本的 VIM 還是有些許不同，對於網頁瀏覽方面應該會有一些對應的設定和功能以增加方便性。有心得再 post 出來。

之前有談過如何設定 Gnu Screen 的方法，如果你常掛在 server 上，那應該對 Screen 這個好用的工具並不陌生。這篇主要是談怎麼 patch 它，來讓它支援 Unicode 補完計畫 (UAO)。

Unicode 補完計畫 (UAO) 對廣大的鄉民來說，可以說是再親切不過的了，BBS 電子佈告欄在台灣相當地盛行，但它底層僅僅支援 Big5，對於鄉民來說，看日文是件再正常不過的事了，但 Big5 畢竟是個急就章推出的編碼 (事實上，它也沒有一個既定的標準，唯一勉強可以稱得上標準的是 Big5-2003)，在當初的設計中並沒有加入日文假名等使用需求。所幸 Big5 有所謂的”使用者造字區”，提供給使用者自行定義新字，也有了後來的”倚天擴充字集”加入了包括日文假名等使用者特殊需求字。

然而，Windows 對於這塊由倚天自行定義的區域，在轉換成 Unicode 時也對應到了使用者造字區，而非它們各自對應到實際在 Unicode 的字，於是造成了 mapping 上的錯誤。UAO 便是為了解決這個問題而產生的，它做的事情只是將這段使用者造字區對應到 Unicode 正確的字。

上面說到的，是針對 Big5 <-> Unicode 的轉換發生在 Windows 的情況，可以利用安裝 UAO 來解決；但因為我的環境是 UTF-8，已經習慣用 Screen 提供的 Encoding Translation 功能來上 BBS 瀏覽文章了，但 Screen 預設提供的 Mapping Table 並沒有處理 UAO，因此這種轉換是在 Screen 內部的情況便無法靠安裝 UAO 來解決，所以必須 patch。

其實許多前輩們已經針對這個部份提供了 Screen 的 UAO patch 以及修正過的 Mapping Table，但他們提供的 Mapping Table 是以 UAO 2.42 所產生的 Binary 檔，這意味著我不清楚它是支援到 UAO 2.42 哪個程度，即使完整支援了 (這反而不好)，Binary 檔也代表它難以再編修和進 Version Control System。

所以我從 Firefox 3 的版本取出了內建的 Mapping Table 文字檔來做處理，Firefox 在 2 的版本已經內建單向處理 UAO 的功能了，所以可以取其 Big5 -> Unicode 單向的 Mapping Table 來做修改。修改後再利用轉換程式編成 Binary 檔便可替代原本 Screen 當中的 “18″ 檔 (也就是 Big5 <-> Unicode Mapping Table)。

利用修正過後的 Screen 便可看到在日文假名以及某些特殊字框的顯示正常很多了；但是實際使用後會發現一個問題，就是對於某些 Double Mapping 的字會優先轉換到 0×8140-0xA0FE 這段擴充區 (這裡所謂的 Double Mapping 是指多個 Big5 的字對應到同一個 Unicode 的字，例如 0xB86D 和 0×82AA 都是對應到 0×7F6E，一個是正常區的，另一個是擴充區的)，而在當初的 Mapping Table 文字檔便是依造 Big5 的字碼來排序，很不巧的 0×8140-0xA0FE 這段擴充區會放置在最前面；而又剛好 Screen 的 Mapping Table 是同時做雙向轉換的，針對這種 Double Mapping 的情況，它會以第一個找到的為優先，這便造成了某些不需 UAO 便可閱讀的字，變成需要 UAO 才能閱讀了，而這篇文章是你打的。解決方式便是將這段擴充區移到 Mapping Table 的最後面，讓正常區的字優先權較高。於是最後的 Mapping Table 表便誕生了，我在每行最後都有加上 UTF-8 所對應到的字。

最後的比較圖如下：

參考資料：

• http://moztw.org/docs/big5/
• Unicode 補完計畫

P.S. 其實 UAO 在本意上是良好的，但是作法我不太推崇，畢竟它不是一個標準，只是為了配合 BBS 所產生的過渡產物，所以讓 Screen 支援 UAO 僅是為了讓瀏覽 BBS 文章更方便而已，在其他環境下，我還是建議以 Unicode 為主，畢竟它是一個標準，支援度又高，Big5 就讓它慢慢走向歷史吧！

在預設的 Mutt color setting 中，單純使用常用的 16-Color 就是用 black, green, red, blue, …, etc 這類的顏色詞來設定；但是在 256-Color 的環境下，必須使用 color0, color1, …, color254, color255 來做設定，關於顏色的對照表，可以參考這邊。

這邊提供一下我的設定 (看是要放到 $HOME/.muttrc 或是另放一個檔案，再從 $HOME/.muttrc include 進去)：

color normal            default         default         # normal text
color indicator         color214        color237        # actual message
color tree              color99         default         # thread arrows
color status            color118        color237        # status line
color error             color196        default         # errors
color message           color196        default         # info messages
color signature         brightblack     default         # signature
color attachment        brightblack     default         # MIME attachments
color search            brightyellow    red             # search matches
color tilde             brightmagenta   default         # ~ at bottom of msg
color markers           red             default         # + at beginning of wrapped lines

color hdrdefault        color33         default         # default header lines
color bold              red             default         # hiliting bold patterns in body
color underline         green           default         # hiliting underlined patterns in body

color quoted            color107        default         # quoted text
color quoted1           color66         default
color quoted2           color32         default
color quoted3           color30         default
color quoted4           color99         default
color quoted5           color36         default
color quoted6           color114        default
color quoted7           color109        default
color quoted8           color41         default
color quoted9           color138        default
# header
color header            color205        default         "^(From|Subject|To|Cc|Bcc):"

# body
color body              color214        default         "(http|https|ftp|news|telnet|finger)://[^ ]+"
color body              color81         default         "[-a-z_0-9.+]+@[-a-z_0-9.]+"
color body              red             default         "(^| )\\*[-a-z0-9*]+\\*[,.?]?[ \n]"
color body              green           default         "(^| )_[-a-z0-9_]+_[,.?]?[ \n]"

# index
uncolor index *         # unset all color index entries
color index             brightgreen     default         ~F      # Flagged
color index             color74         default         ~N      # New
color index             color169        default         ~T      # Tagged
color index             brightblack     default         ~D      # Deleted

這樣設定完成後，如果你跟我一樣使用 $TERM=xterm，沒意外的話會噴出這樣子的訊息：

Error in /home/yzlin/.mutt/color/color256, line 9: 214: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 10: 99: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 11: 118: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 12: 196: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 13: 196: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 20: 33: color not supported by term
Error in /home/yzlin/.mutt/color/color256, line 24: 107: color not supported by term
...

會出現這樣的問題，是因為 Mutt 使用到 ncurses，會判斷 termcap 中，你所使用的 TERM (在此是 xterm) 是否支援 256-Color，如果不支援那麼高，就會噴出這樣子的訊息，這時候有人就會把 TERM 設成 xterm-256color，如此一來，就會成功！？很遺憾的，照樣噴 XD，在 Linux 下，可以單純只設成 xterm-256color，但是在 FreeBSD 下，卻不行！

為何會有如此的差異？其實這個問題帶有一點點歷史的包袱，FreeBSD 預設使用的是 termcap，而 Linux 多半使用的是 terminfo，也因為如此，FreeBSD termcap 會受限於單一 entry 字元數必須小於 1024 個的限制，如此一來，沒辦法將全部的 feature 都包含進去，xterm-256color 就是一個例子，在 /usr/share/misc/termcap 中有一段說明：

# These aliases are for compatibility with the terminfo; termcap cannot provide
# the extra features, but termcap applications still want the names.
xterm-16color|xterm alias 1:tc=xterm-xfree86:
xterm-88color|xterm alias 2:tc=xterm-256color:
xterm-256color|xterm alias 3:tc=xterm-xfree86:

從說明可以看到 xterm-256color 其實引入的是 xterm-xfree86，再詳細去看，xterm-xfree86 當中並沒有 Co 的設定 (Co 指的是 “Maximum number of colors on screen”，相當於 terminfo 中的 colors)，而是引入 xterm-basic 的設定，當中只支援 Co#8，這也是為什麼 xterm-256color 在 FreeBSD 中並不是真的支援 256 色。

若要知道目前使用的 TERM 所支援的 colors，可以使用：

tput Co

注意不是 co 而是 Co，co 是 columns 的意思。

既然無法針對 termcap 下手，那究竟該如何設定使用 Co#256 呢？好在我們可以自行設定一個環境變數 TERMCAP，來強制指定，在 $HOME/.cshrc 設定：

setenv TERMCAP 'xterm|xterm-color:Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm:tc=xterm-xfree86:'

由上面的設定，可以看到我們覆寫了 Co、AB、AF，這樣的設定跟 .screenrc 當中的設定很像，AF 指的是 foreground color 的表示方式；AB 則是 backgound color 的表示方式。設定完成如果要確定是否成功，可以利用 tput 去檢查 Co，出現 256 便是表示成功了，接著在這樣的環境下執行 Mutt，沒意外會看到這樣子的畫面：

這篇主要是講一下之前遇到的一個問題，在 auto-complete 的設定下，會出現：

_alternative:69: command not found: _canonical_paths

雖然好像可以正常運作，但就是覺得怪怪的，後來 google 了一下，發現了別人的解法，原來是 $HOME/.zcompdump 爛掉，把它砍掉，讓 zsh 自動重建就行了。

裡面提到的大多都是建立在「我所認為舒服的環境」的前提上所給的技巧和設定；每個人有每個人認為舒服的設定，這是很主觀的，所以純粹只是當參考。