ego-post!! 即時同步編寫 wiki code 和顯示 html 畫面

對一個時常寫 blog 的人來說, 好的編輯介面相當重要。以前寫過 td-post 以節省重覆輸入同樣連結的時間。但 td-post 有個問題, 每次改完文章又要重執行一次。我常常修來修去, 用起來有點彆手。後來偷懶, 就改用 blogger 的編輯介面。

但 blogger 的所見即所得並不太準, 有時會包含 div 有時不會; 有時會多空行; 複製網路上的文字時, 常會不小心連帶複製到文字的格式, 之後不方便修改。於是得切到 blogger 的 raw html 編輯介面修正這類問題, 再切回來繼續寫, 還挺麻煩的。

去年 Scott 和強者學弟 Will 幫高中學弟妹寫了個 on-line judge。server 端用 Google App, client 端網頁裡嵌了 telnet client, 連到綁好的 local server (透過 QEMU 執行), 用來即時開發程式、編輯和提交程式。並有一個所見即所得的 wiki 編輯器, 用來編題庫。整個工程相當驚人 (或著該說是.......吃飽太閒)！

整個專案有不少地方值得深入玩玩, 而我最有興趣的, 是所見即所得的 wiki 編輯器。畢竟, 用 putty 連到 VirtulBox 裡的 Ubuntu 開發還是方便許多。但 wiki 編輯器卻沒其它替代品。

昨天晚上錯過早睡的時機, 自暴自棄地開始拼湊程式, 今天晚上再改一改就有個不錯的雛型。寫好的東西放在這裡, 有興趣的人可以看看。如同大家所猜, 這篇文章是用 ego-post 打出來的。剛好前陣子在看《料理鼠王》練英文, 就順便用 Ego 命名了。

待做事項

• 提供新的語法用來貼程式碼。

2011-06-02 更新: 有圖有真相, 附上 screenshot:


2011-07-09 更新: 補上自動記錄 link 和發文到 blogger 的功能, 並在 project 首頁補上如何執行。
2012-08-07 更新: 隔了一年多, 終於受不了補上 auto save 的功能。

寫 Blog 好幫手 TD-Post！

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 WordPress 吃的格式，順便藉機練習 TDD，沒想到寫了十小時才完成。剛好最近在看虎x龍的動畫，就將它命名為TD-Post (Tiger x Dragon Post) 吧。

緣起

換過多家 WordPress 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。

寫 Blog 最惱人的事有幾點：

1. 得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。
2. 加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 TDD 我就重貼了許多次。
3. 無法用自己慣用的編輯器。若能用 Vim 寫 Blog，速度必能大增啊！

功能簡介

對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 PmWiki、DokuWiki、TWiki，其中以 PmWiki 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 Trac 的 wiki 格式。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。

接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，TD-Post 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 TD-Post 的位置， TD-Post 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。

程式下載

本程式採 BSD License ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 TDD 流程寫的，測試碼應該很完整。這裡是一些相關資訊：

• 下載：http://code.google.com/p/td-post/downloads/list
• 程式語言：Python
• 程式碼總行數：682 行
• 測式碼：346 行 ( 主要是準備測試的例子 )
• 非測試碼：336 行
• 實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。

其它

有原始碼有真相，最後附上本文的原始碼：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 [http://wordpress.org/ WordPress] 吃的格式，順便藉機練習 [http://en.wikipedia.org/wiki/Test-driven_development TDD]，沒想到寫了十小時才完成。剛好最近在看[http://zh.wikipedia.org/wiki/虎與龍_(小說) 虎x龍]的動畫，就將它命名為[http://code.google.com/p/td-post/ TD-Post] (Tiger x Dragon Post) 吧。   ==== 緣起 ==== 換過多家 [WordPress] 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。   寫 Blog 最惱人的事有幾點： 1. 得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。 1. 加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 [TDD] 我就重貼了許多次。 1. 無法用自己慣用的編輯器。若能用 [http://www.vim.org/ Vim] 寫 Blog，速度必能大增啊！   ==== 功能簡介 ==== 對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 [http://www.pmwiki.org/ PmWiki]、[http://www.dokuwiki.org/ DokuWiki]、[http://twiki.org/ TWiki]，其中以 [PmWiki] 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 [http://trac.edgewall.org/ Trac] 的 [http://trac.edgewall.org/wiki/WikiFormatting wiki 格式]。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。   接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，[TD-Post] 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 [TD-Post] 的位置， [TD-Post] 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。   ==== 程式下載 ==== 本程式採 [http://zh.wikipedia.org/w/index.php?title=BSD许可证&variant=zh-tw BSD License] ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 [TDD] 流程寫的，測試碼應該很完整。這裡是一些相關資訊： * 下載：http://code.google.com/p/td-post/downloads/list * 程式語言：[http://www.python.org/ Python] * 程式碼總行數：682 行 * 測式碼：346 行 ( 主要是準備測試的例子 ) * 非測試碼：336 行 * 實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。   ==== 其它 ====   有原始碼有真相，最後附上本文的原始碼：{{{ #!html _QUINE_ }}}   身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 [http://en.wikipedia.org/wiki/Quine_(computing) Quine] 那樣的技巧，只是單純地取代關鍵字。

身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 Quine 那樣的技巧，只是單純地取代關鍵字。

如何啟動 TWiki Debug 模式

這篇的另一個標題是「TWiki Plugin 讀取和設定 Preference 的方法」，因為要成功地啟動 TWiki Debug 模式，得弄清楚 Preference 設值和讀值的方式才行。

我想這樣的標題就和有人寫了篇《The Amazon.com Customer Service Phone Number》一樣蠢，但實情就是如此糟。一位網友完全道出我摸索這過程的心聲：

TWIKI is SO DAMN CONFUSING on how to debug. It has taken me 4 hours of reading everything and all the docs and I still don’t understand how to turn on debugging. I set DEBUG = 1 in twiki/bin/view/TWiki/ExcelImportExportPlugin, like described in another place (that took me hours to find) http://twiki.org/cgi-bin/view/Support/HeadLinePluginDebugLog

So, the plugin does not work. Twiki documentation assumes you have a PHD in Twiki configuration in order to debug. Seriously it is so confusing. Please someone point out where the docs clearly state where you turn on/off plugin configurations? I have seen docs that say “you do it in configuration” FALSE, you only turn on or off plugins there (and that took me 2 hours to find after installing the plugin and wondering why it did not work)

Will someone please take the to write some documentation that makes sense?

– JeffEller - 30 Nov 2007

問題原因在於 TWiki plugin 的變數設法和取法有兩種，得先弄清楚 plugin 作者是用那個方式取變數值，才有可能把值傳到 plugin 裡。

TWiki 設變數方式很簡單，在任何一頁裡寫如下的 wiki code 即可，存檔後立即生效（注意 * 前有三個空白，後有一個空白）：

1	* Set VAR = VALUE

當這行 wiki code 寫在 TWiki.TWikiPreference 時，就是全站都讀得到，TWiki script 可透過如下的方式取得值並存在 $preferenceVar 裡：

1	$preferenceVar = TWiki::Func::getPreferencesValue('VAR');

然而，Plugin 有另一個讀值的方法，Plugin 可以用如下的 code 取值：

1 2	$preferenceVar = TWiki::Func::getPluginPreferencesValue('VAR'); $preferenceVar = TWiki::Func::getPreferencesValue('PLUGINNAME_VAR'); # 效果同上行

用 getPluginPreferencesValue 讀到的變數名稱，實際上是對應到 PLUGINNAME_VAR，比方說在 EditTablePlugin 裡執行上面這行 code，讀到的是 EDITTABLEPLUGIN_VAR，所以得在 TWiki.TWikiPreference 寫成：

1	* Set EDITTABLEPLUGIN_VAR = VALUE

或是在 TWiki.EditTablePluginTopic 寫成：

1	* Set VAR = VALUE

總而言之，最保險的作法是稍微 trace plugin code，確定它怎麼輸出除錯訊息，得設那個變數名稱才能啟動它，以及它用那個函數取得 preference variable。設對的話會立即生效，也就是將除錯訊息寫入 twiki/data/debug.txt 裡。Code 的改變也是立即在下次讀網頁時生效。

附帶一提，我改 code 時犯了兩個小錯，結果一直沒有效果（也沒看到錯誤訊息）。其一是行末忘了打分號（寫 Python 的習慣．．．）；其二是我在 variable name 後面不小心多加了一個空白，即「getPluginPreferencesValue(’VAR ‘);」，結果就沒取到 ‘VAR’ 的值，浪費了我不少時間啊。

備註

Foswiki 的 ReleasePlan 上指出，本季會出 1.1 版，提高 Foswiki 的品質，我想等那之後再轉用 Foswiki 吧。新版 WYSIWYG 修了一些 bug，而且 NatSkin 很帥，超想用的啦。

Oh my god, TWiki 分家了！

最近剛架好 TWiki ，學會 WikiForm + Template + Search 的技巧後（見 ChangeRequest 的 source code），覺得 TWiki 實在太威了！正想深入了解 TWiki 架構並加裝新功能時，才發現 TWiki 分家了！

整件事的始末可以參閱 Foswiki 的聲明，大意是說 TWiki 的創始人想把 TWiki 商業化，並聲稱 TWiki 的商標、名稱、網域為他個人所有。難怪 TWiki 社群出走，要自己另外弄個 Foswiki。Foswiki 官網的說明還滿清楚的，看起來 TWiki 4.2 可以「簡單」地變更為 Foswiki，這幾天找時間來試吧。而 plugin 的部份，也有和 TWiki 既有 plugin 相容，檔案格式依舊，應該不用太擔心。這裡引用官網 Foswiki Release 1.0.0 - 09 Jan 2009 的說明：

A TWikiCompatibilityPlugin has been created that enables most extensions made for TWiki to work under Foswiki, and to support seamless migrations from TWiki to Foswiki.

…

Foswiki is compatible with content of TWiki releases up to and including 4.2, as part of its design.

文末說明 Foswiki 為了避開 TWiki 定的詞而定的新詞彙，讓我聯想到當初大然倒了，東立接手後的情況啊．．．。Anyway，我滿喜歡 Foswiki 官網的版面設計，看來挺清爽的，現在 TWiki 站上已沒什麼發展，遲早要搬過去，這幾天找個時間來試。

備註

• TWiki 是我裝過最難裝的 wiki，雖說 4.2 版比以前好裝許多，apache configure 可以輕鬆填表產生，configure tool 也很便利，但整體來說，安裝和設定還是很繁瑣。變更 TWiki 到 Foswiki 的步驟涵蓋裝好 Foswiki，所以我覺得不會簡單到那去啦，但也不會像以前那樣難裝。
• 個人認為安裝順手度是 DokuWiki > PmWiki > MoinMoinWiki > TWiki，前兩者用 PHP + text file，裝起來超簡單；後兩者用到 CGI，需要多一點設定。

MoinMoin、PmWiki和DokuWiki editor比較

整理一下最近用Wiki的心得。MoinMoin的GUI editor超威，特別是table的編輯，還可以按右鍵選table/cell property，包含 text/border/background color，text alignment等設定，而且速度很快，GUI editor和text editor之間的切換也很快。有GUI editor後語法也不用查，先用GUI editor產生後再切到text editor看，很方便 ，基本上除表格外，我都用text editor，自由度較高，比較習慣（個人偏好）。

PmWiki和DokuWiki都是text editor加上輔助按鈕，按了可以產生sample code，DokuWiki的功能強一點，還有特殊符號字元表。語法文件方面，PmWiki列得很詳細，分基本和進階的教學，Wiki裝好後預設放在sidebar上，方便查詢。DokuWiki則是放在編輯頁面的上方，點了syntax鏈結後可以看到全部語法和範例，也滿清楚的，文件部份PmWiki和DokuWiki都不錯，MoinMoin因為GUI editor太方便了，我還不知道它的Wiki code文件放在那，因為一次也沒查過。

雖然乍看下PmWiki editor較弱，但我最喜歡PmWiki的Wiki syntax，簡潔易讀。而section editing部份，DokuWiki預設就有，PmWiki要裝plugin SectionEdit，而MoinMoin的作者認為可以用Include page的做法，而不需要section editing的功能，所以沒有這功能。

MoinMoin Wiki心得

簡介

MoinMoin官網

聽老光頭說，在他接觸的open source project裡，用MoinMoin當Wiki的居多，看到Fedora官網做得如此精緻，想來試看看MoinMoin，適合的話可以用來做lab首頁。

MoinMoin是用Python寫的CGI，由於用到CGI的緣故，裝起來比PHP寫的Wiki麻煩一些，由於安全考量，通常各目錄預設都是不能執行CGI，所以apache要多做設定。雖然沒有PmWiki或DokuWiki這麼好裝（1 ~ 5 mins即可裝好），但相較Twiki來說，MoinMoin Wiki好裝許多。

安裝

官網的安裝教學頗為散亂，我大概和MoinMoin Wiki的文件不合，有時寧願自己試也懶得翻文件，總覺得文件的脈絡沒有整理清楚。相較之下PmWiki和DokuWiki清楚多了。

1. 從官網下載
2. 解開後，參照Basic Installation執行安裝的script：
   

   python setup.py install --install-data='/usr/local'

3. 參照Wiki Instance Creation新增Wiki base，直接用網上提供的script較快。
4. 從網頁上按 login -> UserPreferences 註冊account，修改wikiconfig.py：
   

   superuser = [u"YourAccount", ]

   設定permission：

   acl_rights_before = u'YourAccount:read,write,delete,revert,admin Known:read All:read'

   Known表示已註冊使用者，All表示所有人(包含未登入者)，這樣設完包含註冊的人和guest在內，預設權限都是唯讀，需要其它權限的話再改acl_rights_before。

（待修，改天再補完整點）

過程裡有錯誤發生時，可以參照web page的回應，或是看/var/log/http-error.log，error message寫得很清楚。可能會遇到的問題像CGI不能執行、Python版本不對或缺Python module，或是改config檔時沒照Python規定的縮排，懂一點Python有助於除錯。

Plugin

對我來說，一個Wiki的好處，除了安裝容易、Wiki code好寫、權限設定完整外，最重要的是plugin的質和量，這裡簡記一些plugin相關的心得。

對MoinMoin來說，

wiki code: [[XXX(args)]]

parser讀到這行wiki code後，會呼叫data/plugin/macro/XXX.py內的procudure “execute(macro, args)“。

相當簡單易懂的plugin做法，把plugin的python code放到data/plugin/macro/下，即可使用（CGI每次都會重讀，但standalone server可能要重跑server），因此史上最簡單也最有威力的plugin：in-line HTML，只要這麼寫:

in data/plugin/macro/HTML.py：

def execute(macro, args): return args or " "

wiki code example，貼flickr的圖（兩行合一）：

[[HTML(<a href="http://www.flickr.com/photos/12203797@N00/287454598/" title="Photo Sharing"> <img src="http://farm1.static.flickr.com/112/287454598_d5c67feb2a_o.png" width="555" height="376" alt="couplet" /></a>)]]

表格

MoinMoin的table可以做到rowspans和colspans，而DokuWiki和PmWiki做不到colspans。使用table必備的plugin：MiniPage

雖然code有點醜，但透過MiniPage可以在table cell裡塞wiki code，做到像是table內的list，table中的table應該也OK，我沒試就是了，因為wiki code必需寫成一行，可讀性接近於 0，詳細介紹參照MiniPage上的說明。

surge protection

原意是避免被DoS，讓使用者各項操作到限定數量後，禁止對方的操作，但在我反覆測試編輯的情況下，反而是我一直被封，要等一會才能用。雖然可以調高限定數量，但還是很麻煩，後來發生狀況後我就直接砍surge log ( data/cache/surgeprotect/surge-log )。

ps.

• WikiMatrix有四個database用flat-file（用檔案當DB)的比較，寫得比WikiPedia上的介紹清楚。
• Wiki推廣，安裝PmWiki
• DokuWiki推廣

有機會的話，再來寫篇三個Wiki的試用心得，現在是覺得各有好處，不見得那一個比較好或比較不好。

PmWiki：顯示最近更新列表

最近讀了《資訊架構學》，覺得即使是Wiki，也可以構思如何將頁面以更豐富的方式呈現，比方加上最近更新的頁面。

原本 Site.AllRecentChanges 就有顯示所有更新過的頁面，但不方便自訂格式，像是去掉一些不想統計的頁面（例如*.RecentChange），所以自己來弄一個。做法相當簡單，只要用shell script找出wiki.d/下的更新時間即可，再將shell執行結果讀進自訂變數，由wiki page內文裡讀出變數的結果即可。由於做法太簡單了，我就沒找Cookbook裡有沒有類似工具，自己直接黑手做掉了。

修改local/config.php

最上面加入shell script取得更新列表：

function GetRecentUpdatedList() { $result = `ls -tl wiki.d | perl -ne 'print if ! /\.RecentChanges|\.AllRecentChanges|PmWiki\.|Site\.ActionLog|^total /' \ | perl -ane 'print " \$F[-4]-\$F[-3] \$F[-2] [[\$F[-1]]]\n";' | head -30`; return $result; } ... $result = GetRecentUpdatedList(); $FmtPV['$RecentUpdatedList'] = "'" . $result . "'"; #capture contents of $result

在wiki page裡讀出script結果

比方在Main.HomePage裡加上：

!! Recent Updated List {$RecentUpdatedList}

原理說明

這個做法的關鍵是使用自訂變數，參照PmWiki官網說明：OtherVariables，有使用自訂變數的範例。

PmWiki Plugin：ShowHide (=Fold)

官網：ShowHide

注意事項

如果裝完ShowHide沒作用的話，大概是用的Theme不標準，參照作者的回答修改pub/skins/THEME/THEME.tmpl，在</body>前加上<!–HTMLFooter–>。

相關性低的碎碎唸

（對解決問題有興趣的可以參考）

雖然前陣子覺得DokuWiki實在是強到不行，不過PmWiki也有它方便的地方，操作起來比DokuWiki更簡單一點，另一特點是PmWiki有一堆Plugin（PmWiki稱它的Plugin為Cookbook），結果是我兩套都在用，。

Wiki寫久了會遇到兩個問題，其一是想要只編輯單頁的section，其二是想讓顯示時可以把內容摺起來，點了再展開內容。DokuWiki內建section editing，但沒有fold，用fold當keyword找plugin，一下就找到DokuWiki的folding plugin，鳥的是，PmWiki找半天都找不到。

最近Wiki量愈用愈凶，實在受不了沒有fold的PmWiki，甚至想來研究PmWiki自己寫一個。轉念一想，一定有這個plugin，只是作者用的keyword不是fold。於是我用WordNet查fold的同意字，看到”close up”，再回PmWiki官網搜”close”，掃一下Cookbook區的列表，就找到ShowHide了。

ShowHide裝好後沒有作用，但官網上的例子有效，一開始懷疑是PmWiki版本問題，更新到和官網同版本仍然無效後，再仔細翻該頁的問答，發現是Theme的問題。

備註

找ShowHide的過程裡，看到兩個滿有趣的plugin，有機會可以試試：

• FAQToggleList
• HorizontalVerticalMenu

DokuWiki推廣

兩個半月前寫了這篇”Wiki推廣，安裝PmWiki”，近來學Ruby時要貼些表格和example code，發現PmWiki不夠方便，評估了一下，決定改用DokuWiki。

• DokuWiki Syntax Example：真是太美觀了，最棒的是可以輕易處理code，像是<code ruby>能顯示有syntax highlighting的Ruby code。有些語法要用到html tag，不知道一般用戶的接受度如何？
• DokuWiki Installation：抓下tarball，解開讀install.php照著做就是，DokuWiki和PmWiki一樣用text file當database。有提到要看一下Security Issue，但寫得太冗了，等資料多時再考慮吧。
• 別人寫的詳細教學：留著待看。

google一下發現TWiki和DokuWiki的評價都滿高的，但進TWiki首頁找了一下，沒看到syntax example，就不試TWiki啦。

Updated

看了一下權限配制、namespace無限階層結構（和實體目錄對應）、Performance考量（像是cache的處理），預設的DokuWiki看來相當完美，有了DokuWiki，PmWiki存在的目的只是突顯DokuWiki的強大吧！