2011年6月1日 星期三

LoNote個人筆記-簡介


  2011/12/30更新:更新到0.5,blog這樣更新沒完沒了啦!更未來的更新請直接參考google code的LoNote頁面
 
身為一個以說故事為職志的人,方便而可靠的筆記是種不可或缺的東西,但是現存的筆記程式,試用了沒有十個也有八個,卻是怎麼也沒找到符合我心中理想的。 
怎麼辦?筆記軟體是這麼重要的東西,不可或缺啊……
求天不如求人,求人不如求己。想想是每天都要用的軟體,索性自己寫一個來用^_^

因為自己覺得很好用,所以就拿出來分享給大家用啦。
以下真的不是炫燿文XD

LoNote個人筆記

▲大概就是長這樣

特色

既然是看現存筆記軟體不滿做的,LoNote當然有些特色值得一提
  • 以WebKit為核心的編輯器,格式相對自由,只要瀏覽器能顯示出來的東西,LoNote基本上都能顯示和處理。
    • 這意味著你可以直接用LoNote剪貼保存網頁。
  • LoNote的筆記以Html和xml的方式儲存。這是世界通行的格式,不會讓使用者的資料,因為哪天程式缺乏維護,或是轉換平台而無法取回。
  • 按鈕配置合理,和編輯相關的按鈕離編輯區非常接近,而越常用的按鍵,也會出現在愈容易被滑鼠碰到的地方。
    • LoNote是我自己要用的東西,重要的設計理念之一就是要順手方便,你可以注意到左上角的按鈕群,那些按鈕是從右往左排列的,因為右邊更接近我們的注意範圍,而且大多時候離滑鼠游標也比較近。
    • 事實上別說按鈕距離了,我更希望讀者能儘量使用快捷鍵,而不是編輯按鈕。
    • 試著將滑鼠移到按鈕上吧,狀態列會顯示出快捷鍵的具體鍵位。
  • 將顯示空間利用到極限。LoNote沒有多餘的選單列,這讓可視空間得以最大化。
  • 筆記結構化:你可以輕易利用左側的樹狀檢視器(TreeView)與上方的列表檢視器(ListView)排列筆記順序。
    • LoNote的每一個筆記節點都是可以編輯寫入的,它沒有所謂的「資料夾」節點存在,但您當然可以建立一些空白的節點充當資料夾用。
    • 除了在整個筆記中保持結構以外,LoNote也提供了Html的六級標題功能,這使得您的單一筆記內部也同樣能保有完整可追蹤的結構。
  • 自動存檔。您不需要煩惱存檔問題,LoNote總是會存好檔。
  • 整合Mercurial水銀版本控制器。
    • 如果你的電腦上有安裝Mercurial這套自由軟體,那麼LoNote會自動呼叫它,為您的筆記歷程做記錄。
    • 這項功能完全不會干擾您工作,您甚至不會注意到她的存在。但在程式背後,您的每一次編輯,每一次更動,Mercurial都會做紀錄。這意味著您可以在未來將筆記中的任一部份、任一頁回覆到變更中途的版本,甚至回覆已經刪除的內容與記錄。
    • 當然,如果您沒裝「水銀」的話也沒關係,LoNote的其他部份一樣能照常使用。
  • 方便搬移筆記資料:如果你要遷移筆記到別台電腦,把整個筆記資料夾拷貝走就成了,沒有任何其他細節需要擺弄。


下載


需求配置

需要以下程式支援才能執行。
  • Windows or Linux
  • Python 3.1以上版本
  • PyQt4 (針對Python >= 3.1編譯)
  • (選配)Mercurial水銀版本管理器
  • 愛?
具體的系統配置法請參考wiki:建立執行環境



說明文件


其他連結


    94 則留言:

    1. 剛剛從0.4.1更新到0.4.2
      具體更新內容請參看:
      更動記錄

      回覆刪除
    2. 在 archlinux 成功執行了,不過還是習慣用 zim

      回覆刪除
    3. 測試辛苦啦,
      多謝支持^_^

      回覆刪除
    4. 打開範本,感覺比國外的Notecase好用多了。但因為自動存檔的功能,所以我一下子就把範本玩壞了(orz)這功能有好有壞,運氣不好、一時手殘的話,整個內頁的資料就會不見,能否弄個選項允許使用者決定要不要存檔?

      回覆刪除
    5. 哈哈哈,看到你的留言真讓我哭笑不得……

      範本本身就是讓你玩的啦!壞了再下一次就好了。

      關於你說的那個「使用者自行選擇要不要存檔」問題?我想了想,覺得這不太合乎程式的本意。

      因為這是筆記軟體,而不是一款瀏覽器或說閱讀器。所有修改的東西都應該要被確實儲存才對。

      既然隨時隨地都要儲存,那麼我的想法就是要減少這方面的操作量,讓使用者能忽略這樣的動作。

      誤刪重要筆記這種慘劇,我先前在內部測試中確實碰過一次,不過並沒有造成什麼災情,因為版本管理系統隨時都在運作,一個hg revert指令就把資料給復原回來了
      (您也可以使用gui介面的tortoisehg來操作版本紀錄)

      反倒是之前有因為不小心關機,而使未儲存資料遺失,完全無救的案例。所以我還在自己的開發筆記上寫了這個:

      實作更改後自動儲存的功能
      比方說:如果檔案變更超過五秒,自動執行儲存動作
      電腦畢竟會當機,這樣讓人比較安心一點……
      註:這功能要趕快做出來,已經吃到苦頭了!
      (2011/5/31搞定!現在每十秒檢查一次,有更動就會儲存。)


      大概像這樣。

      總之,還是很感謝您的測試與意見啦~

      附帶一提,雖然關係不是很大,不過您有注意到在編輯器裡按Ctrl + Z的妙用嗎?只要沒有經過結構變動或更名之類的操作,在關閉程式之前,可以隨意復原先前的編輯唷。

      回覆刪除
    6. 因應使用者提示,加入時間戳插入功能……
      這邊加入的碼有點硬,泛用性有限,我覺得不是很妥當,以後可能還會再修改,請不要太過介意時間戳的格式。

      話說回來,當時熱血上湧想到就做,改版的速度太快我有點怕怕的。
      我要暫時hold住,以後新功能追加不會發這麼快了。

      回覆刪除
    7. 有空在來玩玩這個有點興趣,我也一直換筆記本軟體有點煩了><

      回覆刪除
    8. 請用請用^_^
      筆記本軟體一直換確實是件麻煩事啊……
      但有時看某功能沒有,又很難忍耐……

      回覆刪除
    9. 請問一下 為甚麼我不能打中文><

      回覆刪除
    10. 設計上是完全可以打中文的,如果不能打中文,那應該是輸入法的問題。

      舉例來說,我使用gcin,在ubuntu上沒有任何問題,但是在archlinux上時,卻沒法在qt程式裡面使用gcin輸入框架。

      對於以上問題,你可以搜索「gcin qt」
      或是參考以下網頁:
      在gtk和qt開發的程式上使用gcin
      PyQt4 + gcin issue
      這些問題可以先參考一下。

      我之前在arch上時,是有成功透過修改環境變數的方式把問題解決啦,不過時間過太久詳細步驟記不起來,偏偏現在arch正處於被肢解狀態,沒法回去找先前的設定檔資料……不過大致上就是上面那些聯結的設定法沒錯--我之前也是在網路上找到中文參考資料的。

      當然你要是用ibus之類的輸入法,那我就搞不懂了(因為完全沒用過)。

      先看看這樣可不可以,如果還有問題請再留言。

      回覆刪除
    11. 我安裝完Qt4-qtconfig 並把預設輸入法改成gcin還是不能打中文耶
      怎麼會這樣呢><

      回覆刪除
    12. 不,重點不是那個qt4-qtconfig
      而是下面這一段:

      export XMODIFIERS=@im=gcin
      export GTK_IM_MODULE=gcin
      export QT_IM_MODULE=gcin
      export XIM_MODULE=gcin
      gcin &

      上面這些環境變數與背景執行碼,必須要放在一個x的rc檔(啟動執行檔)裡,至於是哪個rc……我想應該是~/.xsessionrc吧?

      把上面那串碼放到~/.xsessionrc檔案的最下面,然後重開一次看看。

      還是不行再換用~/.xprofile這個檔案試試,操作同上。(這兩個檔案如果不存在,可以自行在家目錄下新增)

      我手邊現在沒有有問題的機器,沒法驗證手法有無瑕疵,不過記憶中在arch上這樣應該就可以了。(ubuntu上應該一開始就沒問題才對……)

      回覆刪除
    13. 我可以用了
      謝謝大大的指點0.0

      回覆刪除
    14. 不客氣,這種事確實頗傷腦筋的...

      回覆刪除
    15. 喔喔!!~好久沒看到雪凡哥哥了~
      原來在搞這個阿!!!~囧!!!~
      話說我都用tomboy的說

      回覆刪除
    16. 敝人之前將這專案加上setup.py,能夠自產生tar.bz2, 與 tar.gz等 ,但未經完整測試。且近來敝人生活忙碌,一段時間後將把修改檔案給您。

      如果要打包成windows可執行檔的話,在python3建議用cxfreeze (py2exe只能不能用於python3)。

      回覆刪除
    17. 非常感謝支援!

      我自己用cxfreeze包時,總是會漏包一些qt庫,怎樣都包不起來。

      期待您的檔案,但也別因此給自己太多壓力(我自己現在工作也有點忙亂)。如果您不知道檔案該塞往哪裡的話,就直接用mail寄給我好了。

      mail地址在下面:

      Larina.wf@gmail.com

      回覆刪除
    18. 凍仁曾看過這套,之後也試過 TiddlyWiki,最後還是選擇了 Vimwiki 使用,推純 :P

      回覆刪除
    19. 敝人在打包的過程中,發現了一個頗麻煩的問題,且因為其他因素擱淺。今天向ptt python 版向前輩請益後(http://www.ptt.cc/bbs/Python/M.1310621375.A.B5C.html ),解決了關鍵的問題。

      不過 setup.py 還沒完成,敝人會盡快完成的。

      另敝人開了一個 lonote 的克隆版本庫http://code.google.com/r/chenjt30-lonote-repo/source/list?name=0.4.4-beta ,將更新的內容放在那 repo 的 0.4.4-beta 分支,觀迎來逛。

      回覆刪除
    20. 呼,把你的留言從垃圾留言中撈了回來,google的過濾機制真強,失禮了。

      小的畢竟不是專職programer,沒有和人聯手編程的經驗,搞不太清楚如何提供你方便……反正呢!如果您有任何需要或有任何建議(比方說是否要提供你寫入原本repo的權限之類的啥),還請直接對我說不用客氣。

      我這也算是學習如何和人合作一個project啦。

      總之別的不提,一句話:打包軟體辛苦你啦。(拍肩)

      回覆刪除
    21. 最近想把紙本的筆記本換成電子版~
      不過想找個適合的軟體還真不容易一 一a
      如果要考慮到不同電腦間要同步………
      我想死的會很快,
      剛剛大概試用了一下~
      看起來沒有同步的功能,
      (沒有用 Mercurial )
      XP開不起來,
      圖片連結也是開了沒反應~orz

      回覆刪除
    22. XP開不起來?真奇怪。唔,我再測試看看好了,Mercurial不裝也是沒關係的,差別應該不在這裡……

      圖片連結開了沒反應是什麼意思呢?
      總之我再研究一下看看。

      回覆刪除
    23. 經測試我的虛擬機XP也是開不起來,理由依舊不明──看來windows版還是不太完備啊。

      回覆刪除
    24. 作者已經移除這則留言。

      回覆刪除
    25. 再次測試,確認是windows打包的版本有瑕疵

      (在windows xp下裝了python3.2版和pyqt4庫之後就能工作了--但畫面不正常,狀況請參考https://groups.google.com/forum/?hl=zh-TW#!topic/lonote/I4myzYzFt_8 中 Edward Tsai的截圖)

      至少不是我的原始碼的問題,有點高興...該這麼說嗎?

      在裝了python3.2和pyqt4後於windows下執行原始碼,程式倒是運行非常順利.我還是先把那個windows版拿下來好了.

      回覆刪除
    26. OK,藉機再度小更新了一下,把示範的範例整合進主程式中,第一次開啟程式的人自然會見到。
      順便也修了個一直有些礙眼的小bug

      回覆刪除
    27. Windows下已知的bug已經全部擺平了!

      回覆刪除
    28. 在下也是筆記大量需求者,目前是使用Zim,偶然發現雪凡大寫的這個好物,感覺很讚,等下就找時間來安裝!身為不會寫程式的麻瓜用戶,對您的辛勞貢獻只能表達感謝了!

      回覆刪除
    29. 請問要怎麼像word只將縮排功能套用在文章第一排?
      將word文章複製進去後,縮排的資訊會保留下來,但直接打新的文章弄不出來。
      目前是先複製有縮排資訊的筆記來解決,是要插入html檔還是修改css樣式表嗎?

      回覆刪除
    30. 這絕對是要修改樣式表!而且應該有很多種改法才對……

      嗯……如果是我的話,大概會用下面這種改法吧?

      =================

      下面這行放在 CSS 檔案的第一行:

      @charset "utf8";

      下面這三行放在 CSS 檔案的最底下:

      p::before {
      content: "  ";
      }

      ==================

      content 的引號裡放著的是兩個全型空白。這表示在每個 p 段落的前方都會自動補上兩個不可編輯的空白。如果您想要改變縮排長度,就調整空白數量吧。

      至於第一行那個,是因為預設的 CSS 編碼不吃全形字,直接使用全形空白會無法正確顯示。這才需強制指定 CSS 的 charset 為 utf8,讓中文與全形字都能正確地顯示出來。

      嘛哈,希望能解決你的問題囉~

      回覆刪除
      回覆
      1. 可惜這樣子就不能隨意取消空兩格的配置了
        不過還是謝謝你的幫忙,程式很好用呢:D

        刪除
    31. 請問支援 mathjax 嗎?

      回覆刪除
    32. 沒有哦……呃,嚴格說來,我是第一次聽到這東西。

      馬上去查了一下,原來如此,好像很實用。有空時會再去研究看看。

      回覆刪除
    33. Mathjax 有兩種安裝方式。
      第一種是使用時要上網連到 MathJax Content Delivery Network (CDN)。
      這種方式只要在網頁中插入一段 script 就可以了。

      http://bit.ly/S2e5sw

      第二種是使用者要先下載安裝 Mathjax 字型,比較麻煩。

      因為 Lonote 是使用 WebKit 核心,使用第一種方式只要將新建筆記頁預定插入 mathjax
      script 應該就可以了。我覺得是初期比較簡易開發測試的方式。

      我試過的幾種筆記軟體,不是不能處理數學式,不然就是將 latex 轉成圖來顯示。
      可是這樣一來數學式顯示地不漂亮,二來圖也較佔空間,三來不便修改。
      如果 Lonote 能支援 mathjax,應該會是一個很大的特點。
      像前面網友說的 Zim ,因為核心不是網頁引擎,所以短期內沒辦法支援 mathjax。


      回覆刪除
    34. 謝謝告知^_^。

      我目前已經試著在 lonote 2.0 (開發中) 加入了 mathjax 支援,如您所說沒有任何技術上的難點,試用了之後也覺得好用沒話說,唯一問題就是js函式庫愈掛愈多挺影響載入速度的,所以可能不會預設掛載起來。然而,幾乎肯定會提供使用者自行加掛js庫的能力。

      總而言之一句話,我會在未來版本中提供 mathjax 支援。
      ……果然還是多謝您告知這個好物啦!

      回覆刪除
    35. 哦, 2.0 (眼腈發光)。可不可以透露下新增功能和大概的時程呢?

      回覆刪除
    36. 請參考本頁:
      https://code.google.com/p/lonote/wiki/Roadmap_2_0

      上面這份文件是在 2.0 實際開工前寫的,稍微有些混亂,和目前的發展方向也略有不同。不過最前面那些不滿的東西,依然沒怎麼改變。

      進度方面,目前已經完成底層資料設計、完成舊版資料轉新版資料的程式、完成70%以上的網頁伺服器編修支援。這包括新增頁面、刪除頁面、歷史記錄存取、自動滾輪定位、自動儲存、導航系統、透過熱鍵進行基本編輯(還沒編輯按鈕)等。不過像是上傳圖片之類,比較複雜的編輯功能還沒實作出來……總之,編輯現有筆記簿,已經大致沒問題了。

      測試都是直接在 Firefox 與 Chrome 上進行。

      前述所有功能最初都是用純 javascript 做的,不過後來又正式導入 jquery,正在用 jquery 重構主介面程式庫。目前重構已經接近完成,應該可以繼續實現更多功能了。

      與 roadmap 中最主要的差別是,照這樣子下去,我可能會在瀏覽器中直接實現完整的 LoNote client,也就是說,可能會放棄使用本地端介面,而把 LoNote 做成 RESTful 的網頁伺服器,點 LoNote 的圖示只是先將本地伺服器開啟,接著將瀏覽器打開。

      因此,如果我沒有哪裡弄錯的話,日後 LoNote 應該可以跨網路運行,或是在智慧型手機與平版上面瀏覽、編輯。不過因為我沒有買智慧型手機與平版,也從沒用過那種東西(真是非常抱歉,我承認太窮的開發者是有罪的,但……),所以針對手機與平版的介面優化,短時間內仍是不可能的。

      另一方面,先前版本中有些我自己都覺得不好用、沒必要、實作起來卻又非常麻煩的功能也許會被我扔掉。另一方面,新功能多半也會有啦,畢竟換了 client 平台後,有些原有的功能很難實作,但原本實作不出來的功能,也或許可以試著支援看看。

      因為程式碼還很混亂,不是可以直接運行的版本,目前還沒提交到 google code 版本庫中,您目前是見不到程式碼的。抱歉啦。發佈時程也不好說,快則半月一月,慢的話就沒譜了……還請不要太過鞭打我。

      回覆刪除
    37. 你這速度對我來說已是神人等級了。
      像 Zim, Wikidpad 都是用年來做單位的。
      不過既然 Client 已經要移到 firefox 和 chrome 上,
      以後是不是有機會做個像 evernote 的 addon ,
      讓使用者可以輕易地把網頁上的資料給抓下來?
      evernote 目前無法支援 mathjax,mathml 等方程式的顯示,
      幾年前反應過,不過目前看來是沒什麼計畫要做。

      回覆刪除
    38. 抓網頁的功能嗎?
      這個目前沒打算直接支援呢,畢竟我需要的筆記軟體不是這樣用的啊。而且要剪別人的網頁,會有很多例外要處理,很麻煩啊……

      如果偶爾剪貼一下的話,剪下貼上就可以輕易搞定,企圖做成全自動反而容易出錯呢。

      回覆刪除
    39. 是我想的太簡單了。本來以為用了 webkit 核心,只要把網頁存成 html ,再匯入 Lonote 就可以了。再請問一下,Lonote 有辦法顯示表格嗎?我是想把網頁的表格、excel 表格 copy paste 到 Lonote 裏。

      回覆刪除
    40. 可以顯示表格,就和網頁瀏覽器一樣。直接剪下貼上沒問題啦。

      不過它並不支援創建與編輯表格,因為處理表格要很多很多很多很多的程式碼/囧\rz。總之,在我還沒找到一個複雜度可接受的實作方式之前,大概是不可能去搞那個的,我已經強行衝關但又敗退過不少次了……

      另外表格貼上前最好先小心試試(另開一頁或隨時準備Ctrl+Z),我遇過有些表格貼上後居然會刪不掉的,Alt+A全選再刪也沒用。

      回覆刪除
    41. Mathjax 目前沒有支援 latex 的表格指令 \tabular
      不過可以先用 \matrix 指令,
      雖然效果比較差,不過還是可用的。
      例如下面連結的例子

      http://bit.ly/Ww5jTf

      excel copy 出來的資料是用 tab 來分隔欄位,
      如果 Lonote 可以加個 script ,
      把 \t 取代為 $,
      每行最後加上 \\
      在頭尾加上表格指令,
      可許可做為一個臨時的解決方案。

      剛剛看到一個網站給您參考一下,
      http://code.google.com/p/jaxedit/
      有 online 測試的版本
      http://jaxedit.com/
      左上角有個 present 的功能我覺得效果不錯,
      也許要 demo 故事大綱時可以用到。



      回覆刪除
      回覆
      1. 2.0 已經 Release 了!外掛 JS 函式庫的功能已經優雅地加入其中。請試用吧!

        刪除
    42. 雪凡你黑掉了…而且不只這篇,很多篇都如此,尤以 LoNote 相關為最…還有熱門文章第一名那個…(話說這是實做 ScrapBook X DOMEraser BlackOnWhite 功能之後第一次派上用場的機會……該不該感謝你勒?)(這樣打廣告沒有太明顯吧)

      嗯…關於 LoNote ,個人倒是有興趣瞭解幾件事:
      1. 雪凡個人平時怎麼使用它?(eg. 在哪些場合使用,跨電腦?手機?平板?)
      2. 規模多大?比如開了幾架 LoNote 伺服器?一架伺服器上掛了多少筆記本?總共有多少資料夾和檔案?總大小如何?放了多少多媒體檔案或文件檔案?有掛自訂 CSS 與 JS 樣式嗎?等等

      其他有的沒的:
      1. 話說雪凡平時寫作草稿怎麼放啊?個人經驗上寫作草稿似乎是頗需要自動版本管理的東西(幾乎沒啥用但偏偏有時會手殘寫爛,還是要找舊版求救),但 LoNote 新版拿掉了版本管理,那現在是怎麼處理呢?我很好奇。
      2. 部落格文章呢?我猜想搬到靜態站的考量八成是原始碼操之在手以及版本管理,既然回歸了 Blogger,現在是怎麼辦的呢?


      回覆刪除
      回覆
      1. 黑掉是因為以前部落格用淺色底色,那時隨便亂搞,沒想過要讓 code 變乾淨所以才變成這樣啦……

        這陣子陸續有在抽空修正,給我等著。

        LoNote 方面,咱習慣將大部份資料集中在同一台伺服器。筆記總規模大概是 1000 頁上下,約 50 MB,圖與附件佔比極少,字滿滿的。

        我主要將資料集中在本地端,這樣有 bug 立刻修,有不爽立刻實作新功能,對任性的開發者來說很方便。當然這樣一來移動性就差了點,我也還沒想到好方法。

        自己掛些 CSS Theme 通常很快就膩了。不過其中用最順最久的外掛 CSS 是 bootswatch 的 slate theme,黑黑的很有質感。算是推荐的。不過我有把基本字體大小改為 16px 再編譯過。

        草稿方面,我還沒找到理想的草稿處理方式。

        我會用 odt 、LoNote、google drive 與純文字檔來寫稿。sphinx 偶爾也會用。然而不管哪種作法都有缺點。

        另外,稿件的版本管理方面……雖然技術上純文字稿件可以進行版本管理,但實務上這和軟體開發不同,稿件的提交與提交之間沒有合理而明顯的切分點(如新功能或修 bug 這種),改了似乎好點?不改似乎也無所謂?--幾乎都是這種狀況。因為沒有絕對不可接受的失誤,回退版本或挖掘版本庫也沒意義--我到底為啥在幹這個--這種狀況反而更常發生。

        就算某天真有需要回頭去挖舊版,面對那些每行都只改兩三個錯字微調流暢度,但卻一次就改上上百行的變更集,就算跑 diff 也看不出個所以然。結果最後要回退到哪個版本還是很難判斷出來。而就算真的發現某舊版本的特定部份寫得很棒想要回退,但一回退又會把其他東西給連帶復原回來,實在很難說得上能派上用場。

        或許唯一的功能就只是短期備份而已吧?但倘若目標只是短期備份的話,丟進 Dropbox 恐怕是最快的了,繞個大圈用版本管理系統反而礙事。

        ……雖然說我就是想用 XD

        ↑ 完美主義是病,得治。嗯嗯。

        我的部落格文章只有少部份有草稿,大部份都是直接寫在編輯器裏面。備份方面反正 blogger 後台有 xml 匯出功能,倒是不太擔心……該說擔心太多反而沒法動筆,先寫再說。

        刪除
      2. 看來咱們害的病真的差不多呢XD

        草稿一般是不會回退的,我通常用到的場景是:偶爾會覺得先前刪掉或大改的段落改得不好,於是回去查以前是怎麼寫的,然後可以直接把舊版的那部分複製貼回來,或參考著修改目前版本。

        就此方面而言,個人用得最順手的是 wiki 系統,平時就是寫一寫儲存送出,也不必填什麼摘要。萬一出狀況就查舊版本,其中像 MediaWiki 可以逐版本或逐 diff 跳,很快就可以查出我想處理的段落曾經有哪些有參考價值的舊版。

        不過 wiki 當然也有一大堆缺點,最明顯的是它是太龐雜,維護一隻龐然大物只為了管理文章草稿好像不怎麼 smart。再來 MW 有太多維基原生語法,寫純文字或複製外部文字反而要注意一堆語法跳脫。

        其次方便的是 google doc,直接開 doc 寫純文字稿,GD 會自動儲存,所以平時儘管寫就好,出狀況一樣逐版追查來解決問題(GD不能任選兩版 diff,不過反正只是想參考以前怎麼寫的而已,還算夠用)。

        但 GD 主要缺點是資料全在雲端,不可攜,哪天要離線工作,或萬一 GD 有個成住壞空,便麻煩了。檔案可以匯出帶走,但版本記錄可不能一併帶走,即使特別打勾存查。

        VCS 如 Git 或 Hg,狀況大致和您說的一樣,主要適合管程式碼,對於一般文件而言有許多不便:
        1. 每次寫個段落存檔,還要切換到 VCS 去提交,提交還要想提交訊息(因為不能留空),打斷思緒。
        2. VCS 主要設計用於控管整套資料,追查版本時每跳一版通常是列出改動的檔案,而不是改動的文字段落,這點不像 MW 每次切換都直接 show 出該版改了什麼來得直觀。
        3. 很多 VCS 的 GUI 無法精準秀出行內 diff ,中文的 diff 往往也很糟...

        但長遠來看好像還是 VCS + txt 在跨平台和長遠保存方面做得最好?

        我好奇的是,您以前似乎實做過 LoNote 每次儲存都自動接上 Hg 提交新版本,不知實際用起來的經驗如何?嗯…我知道您談過改用 session 系統的心路歷程,但那邊看起來主要是談版本管理在碎碎念或次要、雜項訊息處理上的不足,而不是關於草稿記錄與追查、還原方面,能否也分享分享關於後者的情形呢?

        刪除
      3. 自動接上 VCS 感覺差極了,儘管有部份原因是因為我當時還不擅長使用版本管理系統的緣故。但如今回想起來還是非常難用。

        首先,html 本來就不適合 diff,這包括分行問題,與編輯器產生的 Html code 可能不完全相同的問題--比方說在 fx 編輯過,之後到 chromium 改個字再存一次,就可能有許多空白、分行等(在原始碼層級)會變得不一樣。
        其次,每次提交都沒有語意,很難找舊版資料。偏偏提交數量很大--一分鐘存一次一百分鐘就會有一百個提交,舊資料很難找。
        其三,一分鐘記錄一次看似很頻繁了,但說不定我要查找的東西就只出現在這一分鐘內,剛好就沒記到。
        其四,自動版本紀錄還有一個問題--絕大多數的句子,都是才打一半它就紀錄下去了。事實上版本庫裡大都是這種東西。隨便挑個版本出來,那個想要拿來重用的段落真的是完整的嗎……
        其五,難以製作一個良好的介面來重覽舊版本。雖說要寫也不是不行,但會需要非常多額外的 coding 量,可能比主程式本身都多。再加上上面那些缺點,我實在不想替這個東西寫太多 code……
        其六,大量消耗硬碟空間,也增加 IO 存取,硬碟嘎嘎叫,特別是把附件圖片也列入控制的狀態下更是如此。
        其七,增加環境依賴。

        記歸記了,但根本就是記爽的。沒用啊。

        關於版本紀錄問題,我現在傾向於手動而非自動,只有當用戶覺得當前版本有某種程度的價值時才記。比方說有一個熱鍵,按下後就紀錄當前版本這樣。LoNote 現有的 Section 系統或多或少參考了這樣的概念,不過它還是不夠方便,步驟過多,而且居然還要使用者自行輸入 ID……這是決策失敗!我之後可能還會再修改它。

        刪除
      4. 看起來問題大部分是自動存檔造成的呢 XD

        我向來比較喜歡手動存檔,儲存版本一定是自覺加了或改了重要東西,熱鍵當然是世界通行的 Ctrl+S。看起來您提到的問題不是那麼適用:
        2. 每次存檔都是自己覺得做了 something,雖沒寫提交訊息,但每次跳版應該看得出當時想幹麻或已幹麻。
        3. 記錄頻率操之在已,重要的東西存檔頻率可遠大於每分鐘一次,不重要的五分鐘、十分鐘都不會有新版產生。
        4. 自覺得加了重要東西才存檔,理論上會儲存在整段完成,或未完成但已動了些重要東西之時。

        其次,我設想的是儲存純文字文稿或輕量 HTML 文稿(以換行字元換行,沒有 <p> 或 <br>,通常只有 <H#> <a> <strong> <em> <span style="###"> 這類簡單的格式化元素),拿到外面處理也不會整段弄,只會把一小段原始碼拿出去調整、優化再貼回,因此個人以為 1. 應該不是大問題。

        至於 7. 環境依賴,VCS 版本庫本身有很好的應用支援及匯出、轉檔能力,我不覺得安裝官方程式+GUI是很大的依賴。在該基礎上大改規格或自製接口就難說了,但個人目前似乎還不太需要。

        至於 6. ,理論上不每分鐘自動存檔症狀應該會減輕很多?還有一個考量點是轉換到 Git 系統也許可改善一些,Git 的優點個人寫過推坑文 便不贅述,這裡強調「改寫歷史」的能力:文稿的版本庫是純自看的,比起讓整個版本庫精簡而突出重點,如實記錄歷史反倒沒那麼重要,就文稿版本庫而言,單靠 git rebase -i 透過 edit, reword, skip 就能把中間許多顯不重要的版本記錄拿掉,只留下最重要的幾個版本,並且可以重寫它們的提交訊息。

        就個人看來,自動存檔的主要價值是防止「寫一半未存檔就當掉」和「存檔過程出錯造成檔案毀損」。由於我寫重要的東西會不斷手動存檔,前者價值有限(大部分重要內容可在上次存檔找回),而後者 GDrive 和 Dropbox 就能勝任。此外就前者需求而言,只要自動儲存一個暫存檔就夠了(類似 Office 的自動儲存及錯誤復原,程式執行時自動儲存暫存檔,程式關閉便刪掉)。

        總結來說我要的是像 GDrive 或 Dropbox 一樣在每次存檔時便自動記錄版本,且版本記錄可攜、可長久保存的系統。那為什麼不直接用 GDrive 和 Dropbox?因為如前所述:
        1. 版本記錄留在雲端,不可攜,它們關了便全毀。
        2. 缺乏逐版比對界面,必須手動把一個一個版本下載、編號,再用比對軟體兩個兩個開來比,回溯起來神麻煩!

        刪除
      5. 關於1,也就是 HTML 不好 diff 的問題……我覺得您企圖刪減 HTML 的構思並不理想。先別提具體要如何刪減 Html Code 與將 Code 標準化,您把標準的 HTML 轉成了介於純文字又不是純文字的東西,然後將其塞在版本管理系統裏面……這不是很奇怪嗎?這真能說是我過去寫過的舊版文件嗎?而且究竟有哪些東西要紀錄, 哪些要裁掉,這也難以抉擇。比方說:我貼了一堆圖,變更了圖片寬高,修改了文章末尾的參考用超連結、甚至用 MathML 寫了方程式、這些東西是否就不記錄呢。

        我覺得當然應該要紀錄啊!!我日後想回頭尋找的可能就是這些東西,少了這些訊息不能算是我的舊版本吧……

        此外每個人的標準不同,另一個人可能認為 youtube 的 iframe 連結才是最重要的,那我怎麼辦啊?

        我事實上沒法做出取捨,也不想做這種取捨,連同空白換行,瀏覽器內容照原樣收錄才是王道啊!大概啦……

        關於7,也就是 VCS 環境依賴問題,我覺得以咱們程式宅的標準,這要求確實不高,但是我們的標準應該早就被扭曲了吧喂 XD。看看現實吧阿宅!(呃,我只是想說台詞而已)

        好吧,雖然沒有名台詞那麼強硬,但我的意思你懂的啦。



        關於自動紀錄方面:

        確實自動化的版本紀錄是前述的一大問題點。拔掉自動改為手動,問題應該就能解決大半。然而正如您所說,自動版本紀錄能解決的問題,其實和手動紀錄不同,比方說短期失手誤刪文章等,這時自動版本紀錄反而更有機會救回大部份的資料,而且對用戶的負擔更輕--至少我們不用邊寫邊提醒自己,現在要記一個新版本。隨便輕鬆寫東西的時候,自動版本紀錄就很夠了。

        不過,另一方面,自動版本紀錄應該不用永久保留,畢竟用戶也不知道他們為什麼要紀錄這些東西。一個月以前的舊資料應該就可以扔了。

        更進一步地說,如果不寫版本註解,哪怕用手動版本紀錄方式,我們對舊版文章的記憶追溯能力(告訴自己和現有版本差在哪裡的能力)大概也不可能長過一個月以上,時間超過就兩眼一抹黑,不知那堆資料是幹嘛用的。這不是工具做不到,而是人做不到。儘管我們有 diff 能多少替代語義標籤,但你知我知,用 diff 比對費時又費力,特別是面對數以千計的版本時更是如此。話說這會不會反過來,讓我們不敢太過隨性地按下儲存版本的熱鍵呢?就因為怕版本數量太多?……這也是個問題。

        總之我認為,如果要「有意義地」「長時間」保存版本,語義訊息無論如何都是必要的。

        而這又涉及了另一個難點:如何在文章完成度上切分語義?

        綜上,我認為,版本紀錄應該要有3個層次:

        1. 「自動記錄」:
        由程式判斷自動進行記錄,過時或數量太多就自動清掉,無需保留。
        這個層次解決的問題是:「忘記手動做版本紀錄時,偏偏又碰上意外」。

        2. 「手動記錄」:
        實作方式與自動紀錄相同,但由用戶決定記錄時機:每當用戶按下熱鍵就快速保存一個新版本,無需明確的語義訊息。比方說寫好一個段落後隨手按一下,改完一串錯字後按一下,迅速將版本保存下來。
        這個層次解決的問題是:「輕鬆無腦不費勁,且每個記錄都相對完整的,版本品質比自動紀錄來得高,短期內可優先使用」(畢竟我們總不會句子沒寫完就按保存版本吧?)
        缺點與自動紀錄相同:隨時間過去,我們很快就不知道那些版本能幹啥了--一個「第二段剛寫好」的版本,或「修了一打錯字」的版本又能怎樣?過了三年後能派上什麼用場嗎?我不認為。
        時間一長,這些版本和自動紀錄相同,只會變成版本庫中的雜訊與垃圾而已,反而把真正有價值的紀錄淹沒,故這些版本應該和自動紀錄相同,有個過時的條件,滿足條件就由程式自動回收掉。也能降低硬碟負擔。

        3. 「手動紀錄+語義」:
        實作方式與手動紀錄相同,然而,如果用戶覺得某版本很重要,當然應該能說出這版與眾不同的理由,比方說「初稿完成」、「第二段大改寫前」、「XX 出版社投稿前校對完畢」等等。
        一旦某手動版本紀錄的「語義欄位」不為空,程式就自動將其視為不該被自動回收,而會永久保存下去。
        畢竟也只有這些紀錄我才可能在很久後退回來查找內容。

        我想像中,關於察看舊版本的介面,以上三種紀錄的超連結都會依據時間排列在同一個表格裡,藉此分出各版本新舊。但其中自動紀錄可被設為灰色、手動紀錄被設為正常色,有語義訊息的紀錄則在列表中直接顯示相應的語義訊息。

        因為缺乏語意的記錄都會逐漸被清掉,文件的版本紀錄會逐漸被篩選為只剩下「近期的」或「含語義」的記錄,因此版本庫的大小會隨時間壓縮變小,而品質與可用性則會隨時間自然提高。

        手動記錄中的語義,也可以原本沒有但事後追加,並不需要一次到位--如果過一陣子才覺得某版本有長期保存的價值,在該版本被回收前替它加上語義就行了。

        很好,之後就這樣整合進新版 LoNote 之中吧?應該沒什麼大問題才對。這下要寫新版的動力又多了一項。
        與現有的 Section 系統整合方面嘛……就每個單獨 Section 都對應一套這種系統好了(暫定)



        哈哈哈,拜讀 Git 推坑文,老實說之前就讀過了。
        話說我最近也寫了 Mercurial 推坑文,且完全是針對著 Git 進行比較,過陣子應該就會發佈。歡迎參考看看。

        刪除
      6. 噢,這是我的問題,我腦中的比較基準和您完全不同XD

        我幻想中的草稿自動版本控管系統是相當接近維基百科的,比如我記事本開一個 txt 檔案寫份草稿「Re LoNote個人筆記-簡介.txt」,每次儲存時系統就自動幫我提交新版本這樣。

        由於是草稿,最終通常是要貼上其他地方的,比如我貼在這裡的留言便是輕量 HTML 的代表之一,裡面肯定不會有什麼 <br> 和 <p>。

        當然我肯定可以建個版本庫,每次儲存草稿就切換到 VCS 去手動提交(嗯...強迫填提交訊息真的很煩,不過自備個不動腦訊息便可,比如 "" "nul" 之類),甚至可以在多次儲存後某個我覺得有意義的狀態再手動提交有語義的版本,這樣版本庫肯定會非常簡潔,不過也就失去了前面說的「方便」的優點。

        這之中還蘊涵著自動版本控管,因為這 txt 檔沒意外是會開設在 GDrive 或 Dropbox 資料夾下的,萬一真的毀損,也撈得回來。

        ←幻想到這裡覺得好像不錯,因此咱實做了一下...實驗數據可參考這裡

        但您說的也完全正確,就 LoNote──一個富文本編輯器──的角度來看,除非每次儲存前強制 HTML source beautify(←別小看它,它確實是個可以考慮的 solution),否則和版本管理系統整合一定慘不忍睹,別的不說,光是 LoNote 中 Enter 換行是無空行 <br> 這點,肯定會讓儲存出來的原始碼充滿著可怕的一行文吧XD

        總之,我基於對維基百科版本控管的絕佳印象,幻想著:這樣的個人草稿控管系統應該會很棒吧!然後這裡想看看有沒有人實做後得到了慘烈的教訓,從以上討論看來您的經驗和我想的情境並不相同,這背後也許暗示了某個雙面事實? (1) 純文字、準純文字草稿版本管理很好用,快實做啊!(2) LoNote 版本管理爛透了別幻想。

        話說我之前曾想過一個系統是支援多種檔案的,套用在 LoNote 的想像情境是,可以新增 html 富文本紙張,也可以新增純文字紙張、md 紙張、rst 紙張等等,當然如果要版本管理,應該會全部都做,不過此時在寫作草稿的方面,應該會有更大的誘因選擇不要開 html 富文本紙張,而在其他幾種手刻紙張中進行,這些草稿應該能獲得不錯的版本管理效果?

        至於 Hg 倒推文,老實說除了好上手咱實在想不出 Hg 有什麼好,不過一位 Linux 使用者居然最終選擇 Hg,應該多少拿得出點好理由吧?總之咱們走著瞧囉嘿嘿。

        刪除
      7. 又進垃圾箱了……總之再撈出來。

        原來如此,如果您憧憬的版本管理條件是「運用現有 VCS」、「主要保存純文字」、「每次稿件存檔時自動觸發版本保存」、「暫時不去管撈舊資料方不方便以及版本總數多不多」的話,這說不定其實超簡單的。

        您有沒有考慮找個 DAEMON 程式(有現成的,比方說 incron)來監視您的草稿資料夾,每當資料夾中任何檔案改變時(將暫存檔與 .git 檔案設為例外),就觸發一個腳本,腳本裡簡單裝著 git add . && git commit -m "[AUTO] Anonymous commit" 之類的指令。

        如此一來您應該就可以輕鬆完成夢想了。有興趣的話試試看吧。

        刪除
      8. 對了你的連結怪怪的我看不到,看需不需要補一下。

        刪除
      9. 作者已經移除這則留言。

        刪除
      10. 不能用啊 (騷頭)...改成這個好了...

        其實我仔細想想,筆記的確不太需要版本管理,至少咱 Evernote 免費版用了 3 年也沒因缺乏版本管理感到太大不便,少數個別情況(這舊版到底要不要刪掉好猶䂊啊)fork 一則通常就可以了(或者用您的 session 方案),但文章草稿是不一樣的性質,每次改動段落多少反映當下的心路歷程,很多靈感是蘊藏在其中的,有個版本管理機制應該比較理想。

        筆記和草稿分成不同系統會不會開始亂啊,不過老實說好像的確沒有合併的需要呴? (←神經病自言自語中,免理會)

        偏偏麻煩的是世界上不只筆記和草稿兩種東西而已,還有很多灰色地帶的東西,比如 M$ office 引入後盛行的文件檔、試算表檔、投影片檔,這些老實說有時也滿需要回溯的,不過富文本的版本管理總歸一個麻煩。現階段還是留給 GDrive / Dropbox 處理自動備份 + 重要參考版本 copy 一份來解決吧。

        至於 incron ,嗯...是 Unix 用的,可惜咱還在暈到死的紅塵中打滾orz 稍微查了一下暈到死平台上似乎 vbscript 就能寫出監聽檔案修改的程式,要呼叫 cmd 應該也不難,有空來實作看看,感謝啦!

        回到 LoNote 的話題,不太確定您打算怎麼實做,但千萬別自己開發版本管理系統啊。版本管理系統是很複雜的東西,自行開發的規格其流通性和移植性很可能大有問題,別想不開拿生命開玩笑啊。如要沿用現有的版本管理系統…就個人所知 Hg 非常抗拒更動歷史,如要自動記錄版本,又要系統在一段時間後自動清除某些歷史,在 Hg 上實做恐怕會有不少困難。

        若只管記錄不管自動清除,應該是很簡單的,讓我們想像自動儲存就在提交訊息填上 <lonote auto save>,手動儲存就填上 <manual save>,語義儲存就填上輸入的訊息,對一個 Hg 使用者而言,要在 n 年後篩選出版本庫中老舊的 <lonote auto save> 和 <manual save> 清除應該不困難吧。

        刪除
      11. 關於 LoNote,我當然不會開發一個「完整的」版本管理系統,但是自己稍做開發恐怕還是必須的。理由如下:



        1. 我要讓「每一頁」的版本歷史都分開,而不是對「整個倉庫」做版本記錄。

        每頁的版本紀錄分開,這樣才方便搬移、刪除、進行諸如將筆記頁從某人倉庫轉移到另一個倉庫等這類操作--每頁筆記頁都能夠作為一個獨立的元件來移動位置,藉此降低偶合,而不影響到系統的其餘部份。總之,我企圖紀錄的是個別檔案的內容,而非資料夾結構。

        但現有的 VCS 並非基於這種假設而設計的,除非我替每個單獨頁面都建一個倉庫……雖然不是一定不行,但說不定會在某些意料不到的地方出問題,比方說效能或壓縮率什麼的,而且檔案總數顯然也會爆發性地增加…… VCS 畢竟不是給我們這樣用的。



        2. 效能差勁

        我希望系統能隨時間,自動且大量刪除無用歷史。這有兩個目的:控制版本紀錄佔用的大小,以及避免收錄過多無用的雜訊版本,好方便用戶撿選資料。

        不用說,這個刪除量會很大。

        事實上,因為大部份的版本都會被回收,就整體上來說,刪除的速度幾乎就和紀錄的速度一樣快。然而無論 Git 或 HG,這些 VCS 都不是以要大量變更歷史為前提而設計的。

        舉例來說,我在一個月內,於版本庫中或自動或手動地紀錄了 1000 個版本(平均一天三十個),而隨著過期時間到達,系統準備要刪掉最早的前五個(因為最早的版本總是最早過期),這種狀況下,以 VCS 的觀念來說,我其實不是真的要「刪除」某些版本,而是要將多個版本壓合為一個新的 commit 版本。git rebase -i 後進行 squash 操作,或是 hg histedit 的 fold 操作,就是在做這些事情的。

        然而這種歷史重寫不容易實作成自動化腳本,更頭痛的是,每次這樣執行,您會注意到後續所有 commit 的 hash 值都改變了,而這也意味著「每次改變歷史時,VCS 會重寫後續所有版本」(在本例中約為 1000 個)……效能上極其要命。

        這還不算完,過了一天後,我新添加了十五個版本,同時另外二十個最舊的版本再度到期……囧rz

        這是無限迴圈的效能地獄。

        說起來,Git 與 Mercurial 都有重寫歷史的彈性,但那僅僅只是彈性而已,他們不是設計讓我們三天兩頭重寫幾乎整個版本庫的。(順便一提,Hg 只是預設沒開啟用來編輯歷史的插件而已,而不是缺少這種能力)

        以上問題看似是定時自動回收造成的,那麼如果不要「定時自動」地刪除舊版本呢?比方說隔很久才清掃一次?或讓用戶手動清掃?

        但那麼做的話,會造成倉庫大小不穩定地收縮膨脹,時而很大,時而較小,而不能總是平穩地維持在一個比較小的水平。而依據短板原理,系統有時會很大的意思,就表示您總是要假設他會很大,如果你用了容量較小的假設,隨時可能會空間耗盡而掛掉。這對於將資料放在小空間,如隨身碟上,或租用網路空間的人會是致命的問題。

        此外,如果沒有自動清掃紀錄的話,就意味著用戶必須要手動決定清掃時間,這會使用戶不得不分出額外注意力來關注系統維護的問題,而不能集中在內容編寫之上。這雖然不是絕對不能接受的選項,但我想應該能避就避。



        3. 用 VCS 不容易變更提交訊息。

        如果我要變更一個已經提交過 commit message,等於要重寫後續全部版本,這同樣是效能問題。



        4. 系統依賴

        我之前提過了,用 VCS 會增加系統依賴,不說別的,隨身碟用戶立刻就再見了。而且雲端執行環境中,也不見得有程式所需的版本管理系統。



        5. 功能過剩

        雖然您覺得這不算什麼,但真的不是所有人都會/都想用 Git 或 HG 這種正規工具來管理版本。甚至絕大多數的筆記用戶,連最基本的自動備份功能都不需要。強迫扔給他們一套全功能的版本管理系統很難說是個好主意。特別是在這套系統有其他缺點的情況下。



        6. 說到最後,在這裡用 VCS 的好處是什麼?

        1. 「少寫些 Code」:真的會少嗎?
        2. 「通用性與對用戶透明度」:如果我將版本檔案存成純文字(或許加上壓縮)的格式,通用性只會更高,而且還不用依賴除了編輯器以外的任何程式。
        3. 「效能」:前述已經說明了效能正是在此使用 VCS 最大的問題之一。
        4. 「容量」:如果經常進行回收操作,容量消耗應該會比我自己寫的版本小,但反之則難說。
        5. 「穩定性」:呼叫外部程式,並在多進程環境下解決問題,穩定性並不容易保證。

        基於以上:「效能低落」、「容量消耗」、「橋接困難」、「透明度」、「系統依賴」……等一卡車理由,自行開發一個有限的版本管理模組是必須的。

        這不是重造輪子,也不是 VCS 不好,只是 F1 賽車不適合在山區跑而已。



        我已經很久沒有思考過這個問題了,和您聊天讓我想起不少當初放棄這個架構的理由。雖然打字很累,不過很有收穫啊。



        最後補充資料:

        如果您想要管理「富文字文件」的版本,不用寫程式,我剛剛查了一下,開源辦公軟體 LibreOffice Writer 中就有內建版本管理系統(主選單→檔案→版本)。文件的多個版本可以作為存檔的一部份,被存在同一個檔案裡面,而且程式中也包含了版本比較的功能。雖然我沒法將新建版本設定成熱鍵,可用性依然頗高。

        記得 MS Word 好像也有同類功能,不過我手邊沒有程式可測,具體就要請您自己查一下了。

        刪除
      12. 唉...您分析的很好,VCS 確實在這方面有很多的不便之處。

        不過自製版本管理系統仍然是大工程,雖說是開放格式人人可讀取,但實務上人家要移植得自己寫套腳本或程式就是麻煩,而且咱這種小咖開發出的版本管理規格極可能丟三落四,改版時不斷變動data scheme,能保證每次變動都轉檔順利嗎?這又讓文件的長期保存增添許多未知數...

        除了版本管理,您恐怕還得自行開發比對程式呢,不要環境依賴,要自己寫套像 vimdiff, worddiff, kdiff 功能一樣強大的程式嗎?

        況且如您之前的分析,您也認為 HTML 版本管理很雞肋了,不是嗎?

        如果只是要防止誤刪這種等級的自動儲存,應不需版本管理系統,如前所述,只要像 Office 一樣在執行期自動儲存一個上次版本即可。

        總之開發的不是我,就……祝福您囉。順帶一提,果真打算寫版本管理系統,或許可以參考 DokuWiki (PHP),DW 的版本記錄是用純文字和 zip 儲存,應相當符合您「各別文章儲存」「容易修改」「容易刪除」「容易自動化」等需求。至少在眾多 wiki engine 中,DW 的系統是我見過最體貼最平易近人的。(但 zip 仍有 Winows/Linux 跨平台的檔名相容問題要解決)


        感謝告知 LibreOffice 的版本記錄功能,不過這功能實在做得有點...傲嬌(Ctrl+S 不會建立新版本,只能關閉時儲存新版本是怎樣),而且 LO 目前仍有許多功能上的不足(不是那種界面上的小瑕疵,是牽涉資料如實保存的問題),至少我個人還不能滿意。至於 M$ Word 我試了試 2010 似乎還沒看到這樣的版本記錄及管理比對的功能,不知是不是我忽略了什麼...

        刪除
      13. 我不是說 HTML 不能或不該進行版本管理啦。看看前面的留言,我是說「HTML 原始碼不容易 diff」。

        而之所以我先前會提到 diff 的原因,也是因為您有兩個夢想:「儘量不要刪除任何版本」以及「用現有 VCS 管理版本」。而偏偏您想要保留的版本中,又包含了許多「沒有 commit message」的版本。

        既然沒有 commit message,那麼 VCS 中唯一能識別出語義的方式,就只剩下 diff 啦。這時作為唯一工具的 diff 就變得超重要了,因此我才提出「HTML 原始碼要做 diff 不方便」這件事。

        不過,如果依照我的設想(而不是您的夢想),除了近期版本外,其他版本都有 message 的話,diff 就沒那麼重要了。

        換句話說,會因為 HTML diff 問題而煩惱的,是您憧憬的框架,而非我的想法。會因此頭疼的人是您才對啊。您一定是被我的話嘮給繞暈了。

        不過,雖然我的構想不像您那樣依賴 diff(因為有靠 message 來區分版本),但如果有 diff 可用畢竟是挺好的。說到這個,我剛想起來了,我有在 LoNote 2.X 的後期版本中實作「HTML 的版本比較」功能。而且是 HTML「渲染後」的版本比較,而非 HTML 原始碼的版本比較。畫面效果還算挺不錯的,就連圖片或超連結更換了都能顯示出來。

        如果順利的話,我想相應的 HTML diff 技術,應該可以很容易地搬移到未來的 LoNote 上。這個功能沒有在 LoNote 3 實作不是因為他本身不好,而是因為 LoNote 3 的 Section,在語意上並非指「文件的變更版本」,裝上這種東西語意會變得很奇怪嘛……

        總之,要不是您提起,我差點都忘記自己早折騰過這件事了 XD



        「防止誤刪的自動儲存很容易取代」

        --關於這點,我想您說的完全正確。替代方案有許多,像 Dropbox 就是最方便的一種,不見得寫 code。我目前僅僅是想:反正底層實作是一樣的,我做了手動版本儲存後,自動儲存就只是順便而已, code 應該沒差幾行,也不用引入額外的框架與概念。總之就是順便。

        當然這不是那麼重要,要是我突然發懶或許就算了(←喂!)



        關於改版資料格式可能會改變的問題……

        這當然是會變的,LoNote 的資料格式從最早到現在已經大改版了三次,日後只要有必要,我當然也會繼續改版,努力讓它變得更好。

        此外,確實如您所說,我沒法保證程式在轉檔時絕不會將您的資料故障轉壞。不,別說轉檔了,我甚至沒法完全保證您的資料不會在日常使用中損壞。不知您能否理解,事實上所有自由軟體都有「不附隨保證」的特性,包括 Git 與 Linux 內核都是如此。

        不過即使如此,就如您所知到的那樣,我們這些作者也總是儘可能地把程式做到最好,畢竟這世界上最常使用某程式的傢伙,十之八九正是作者自己--我只能向您說,如果我的程式中有什麼問題,最可能碰上倒楣事的多半就是我本人了。您要是依然擔心不安,雖然我能理解,但我也實在無法再多做什麼,只能說聲抱歉了。



        DokuWiki 是我目前最有興趣的 Wiki,他的設計理念我很喜歡,我會參考的。謝謝。

        其實我不太清楚你說的「LO 資料沒有如實保存」那是怎麼回事,總覺得好像聽到祕辛了,不分享一下嗎?

        MS 的問題幫不了你囉,我已經快退化為 Windows 白痴了 XD

        刪除
      14. 1. 看看咱既然完全忘了自由軟體界的基本遊戲規則了,真是千不該萬不該啊,掌嘴掌嘴!

        2. 「HTML 渲染結果的版本比較」看起來挺酷的,能問問是哪個版本,順便伸原始碼連結嗎?

        3. 嗯…不才在 DokuWiki 打滾頗久,貢獻過一點核心原始碼,開發過幾個 plugin,也有正在運行的專案,算略懂略懂吧。如有什麼地方不太瞭解,也許咱們可以一起研究研究(不過要等我有空就是)

        4. LO 的問題啊...我遇過的大概有幾個:
        (1) 不支援行內文字的框線格式 (怨念版,慎入!):這格式擺明是個 HTML 標準,不支援實在很離譜!而且 M$ Word 上一堆人用這格式標重點,你要人家換平台怎麼面對這些格式?
        (2) 對 Unicode ExtB+ 字元支援不好:好啦這不是大夥兒都要在意的,但本人得和這些字元打交道,所以無法容忍。
        (3) 存檔後資訊遺失:本人曾在 LO 改了些東西後儲存,下次開啟時有些東西不見了,而且重複多次結果都一樣。印象中是圖片的儲存路徑出錯導致之後看不到,當時太忙便直接換到其他軟體,宋詳細測試及記錄,所以只能留點和謠言差不多的牢騷XD

        刪除
      15. 2. Code 在這裡,下載 2.2.X 系列 windows 版應該就能試玩了。其實就只是很簡單地,在有變化的元件上加上綠色或紅色的半透明背景而已。至於如何計算變化則是使用 lxml 的 htmldiff,我扔出兩個版本,他幫我算好,我只要套用結果就行了。不過 lxml 組件相當肥,所以我寫程式時是把他視為可選組件,有裝才有 diff 功能,反正我想也不是每個人都需要。

        4. 原來如此,LO 的問題拜讀了。我沒用得那麼深入,還沒被咬過,謝謝提醒囉!

        刪除
      16. 唔唔……看起來 Lonote 2 很…精緻啊……會放棄這麼精美的架構,背後應該有什麼祕辛吧XD


        我想到個有趣的點子,既然說基本上只有手動儲存且有輸入版本意義的版本記錄才有實用價值,那麼……不如就讓 session 和版本記錄合體吧!

        具體做法很簡單,就是在新建 session 的對話盒裡加個勾勾讓使用者選擇新 session 是否要複製目前 session 的內容,以及預先在 session 名稱欄位填入目前時間的 timestamp。這樣使用者很容易就可以把新 session 變成一個「版本」,他可以在名稱後面加語義,或者寫在描述裡。如果不想要,只要取消勾勾,刪掉預填的 timestamp,就可以完全照以往的 session 用法走。

        然後我們可再比照 Lonote 2 的做法,設計個界面讓使用者任選兩個 session 比對 HTML 差異。

        這麼一來,session 就是現成的強化版版本管理系統了。

        稍微模擬了一下,大概會長成...這副德性吧?前面加隻毛毛蟲當然是為了讓「版本記錄」與「一般 session」在視覺和排序上有所區隔。


        然後還有個不好的消息, Lonote 又出包了,為了測試我關掉了 Lonote 3.2.8 伺服器,再開啟 Lonote 2.2.3,之後關閉 2.2.3 再啟動 Lonote 3.2.8 就死當無法啟動了……真相在此

        刪除
      17. 先修問題,其他等會兒。



        你是不是把 2.x 的筆記簿與 3.x 的筆記簿放在同一個資料夾下了?兩個版本的筆記簿格式很像但不一樣。請將雙方筆記簿檔案分開,應該就可以了。

        如果您的 2.x 與 3.x 的 config 目錄是分開的話,那就真挺怪的,他們應該是不會干擾彼此的。總之下一步請檢查 3.X 版本的「config/lonote/book 目錄」 -> 「各個增量資料夾」 -> 「modify.xml」,打開來看看有沒有啥問題。

        其內容應該會像是:

        <modify>
        <delete name="pages/05bcd201-4418-43aa-8855-7130acfa41b7/sections/talk"/>
        <delete name="pages/05bcd201-4418-43aa-8855-7130acfa41b7/sections/main"/>
        <delete name="pages/05bcd201-4418-43aa-8855-7130acfa41b7/sections.xml"/>
        <delete name="pages/05bcd201-4418-43aa-8855-7130acfa41b7/resource.xml"/>
        <delete name="pages/d091d088-4b37-4b9e-b49b-11ff54bc32b7/sections/main"/>
        <delete name="pages/d091d088-4b37-4b9e-b49b-11ff54bc32b7/sections.xml"/>
        <delete name="pages/d091d088-4b37-4b9e-b49b-11ff54bc32b7/resource.xml"/>
        <delete name="pages/78023bc3-0a8b-4775-afb8-f1326e3f5929/sections/main"/>
        <delete name="pages/78023bc3-0a8b-4775-afb8-f1326e3f5929/sections.xml"/>
        <delete name="pages/78023bc3-0a8b-4775-afb8-f1326e3f5929/resource.xml"/>
        <delete name="pages/eef9ad65-0ccd-44c8-ba32-954c5fa02227/sections/main"/>
        <delete name="pages/eef9ad65-0ccd-44c8-ba32-954c5fa02227/sections.xml"/>
        <delete name="pages/eef9ad65-0ccd-44c8-ba32-954c5fa02227/resource.xml"/>
        <delete name="pages/451c3af4-90d8-4f7c-81fc-0c59e141a815/sections/main"/>
        <delete name="pages/451c3af4-90d8-4f7c-81fc-0c59e141a815/sections.xml"/>
        <delete name="pages/451c3af4-90d8-4f7c-81fc-0c59e141a815/resources/Apache_License"/>
        <delete name="pages/451c3af4-90d8-4f7c-81fc-0c59e141a815/resources/lo_1_5.resized.png"/>
        <delete name="pages/451c3af4-90d8-4f7c-81fc-0c59e141a815/resource.xml"/>
        <delete name="pages/9d1b1547-448b-447c-b567-ccc44b24acf2/sections/main"/>
        <delete name="pages/9d1b1547-448b-447c-b567-ccc44b24acf2/sections.xml"/>
        <delete name="pages/9d1b1547-448b-447c-b567-ccc44b24acf2/resource.xml"/>
        </modify>


        看看有沒有啥不對勁之處,其中 modify 是關鍵字不能動,內容倒是可以一項沒有。畢竟錯誤訊息提到的是格式不對的問題。

        請查查看每一個筆記簿的增量資料夾。



        話說你有沒有用 Dropbox 之類的同步軟體?

        刪除
      18. 1. Lonote 2.* 和 Lonote 3.* 完全獨立為兩套資料夾,資料檔也沒共用

        2. 有開著 Dropbox 和 Google Drive,但 Lonote 相關檔案沒有放它們目錄下

        3. 我不知道所謂 modify.xml 正常和不正常要怎麼診斷。不過反正只是測試檔案很少,我貼上整個 modify.xml 好了:

        <modify><delete name="pages/ad74c92b-97ed-4e00-b975-849f0942a844/sections/20140714105312" /><delete name="pages/ad74c92b-97ed-4e00-b975-849f0942a844/sections/下一站" /></modify>

        4. 我發現原來我一直把 section 寫成 session ,為什麼會這麼腦殘呢orz 總之下次不會再搞錯了……(應該吧)

        刪除
      19. 哇!您抓到了一個 bug!

        這個 bug 與 2.X 版本無關,只是剛好碰上您重啟伺服器這件事而已。問題肇因於 modify.xml 檔案儲存時編碼沒設為 utf-8。

        修復方法如下:

        1. 用編輯器 (記事本就足夠) 打開檔案,另存新檔複寫原本的檔案,選擇編碼為 "utf-8"。如此就能將無法啟動的問題解決。
        2. 為了避免以後繼續寫入錯誤的編碼,請下載最新版 LoNote (>=2.3.10) 使用。

        如此應該就 OK 了,如果還是不行再鞭我。總之再次感謝您的幫忙啦。

        刪除
      20. 回到原本的留言。

        如果您比較喜歡 2.X,也可以只用 2.X 版本哦。沒必要跟隨我的節奏升級。

        2.X 系列的介面算是我當時的得意作吧,它很有技術性,很具有巧思,可以把數以千計的樹狀結構動態壓入一個頁面中讓使用者瀏覽,但其設計也非常討巧。而隨著時間過去,我開始覺得這種討巧並不是好事。比方說為了滿足那些特殊效果,code 變得很難維護,此外他對瀏覽器相容性更低,面對縮放問題時更容易跑版,過度依賴「滑鼠滑過」操作使手機用戶難以使用,CSS 渲染負擔過重有時會讓瀏覽器短暫 lag 等都是潛在的難點。

        而在技術面以外,每次跳頁必須多次移動滑鼠來定位,所需的滑鼠移動時間與距離都更長,過度消耗使用者的集中力 (使用者需要更加集中精神才能操作它),這也是個問題。

        與之相比,三版則放棄這種極度依賴作者天才的介面,改使用更容易理解,在各種操作中相容性都更高的系統來取代。換句話說就是改用正攻法來解決問題。



        關於 Section 與版本比較……

        Section 可以作為版本的代用品,但他本身不是以版本為基礎而設計的,這是 LoNote 3 的概念。我覺得讓 Section 與 Section 間進行版本比較並不妥當--那就像維基百科的正文與 Talk page 互相比較一樣……不覺得有哪裡搞錯了嗎 囧tz

        這麼做事實上對用戶也不方便,因為 Section 應該要能讓用戶輸入更多的附屬資料,比方說 name,description,變更時間等,而版本紀錄則正好往相反的方向發展--讓用戶介入得更少。版本紀錄只要有 message 就行,甚至連 message 都不需要。

        如果將這兩者混合,用戶每次按下儲存熱鍵時,他們都可能會被介面上的一堆選項干擾到--除非我用一個專用熱鍵把新建版本的操作全部封裝起來。

        在編程上也不便,畢竟我在後端依然要區分兩種相似但用途不同的資料類型,標準的 Section 與 版本紀錄顯然不該出現在同一個列表裡面 (雖然您說加隻毛毛蟲可以區隔,但……總之我覺得不甚理想),而可對其進行的功能操作也不相同--比方說語意上的 Section 要能接上編輯器介面,而版本紀錄則不應該;版本紀錄或許可以進行版本比對,而語意上的 Section 之間進行版本比對則沒意義。總之會有很多例外狀況與邊際條件需要處理。

        功能上也會出現短缺:畢竟,如果以 Section 來實作版本管理系統的話,那麼就難以替「語意上的 Section」記錄版本了--看看維基百科吧,他的 Talk 頁也是有版本變更紀錄的,而不光只是內容頁有而已。

        基於以上理由。Section 可以作為版本的臨時代用品,但是如果要真正製作好用(而不是有就好)且具維護性的版本管理系統,將版本的概念獨立實作是必須的。

        至於 HTML 版本比較方面,既然技術都已經研究出來了,只要重新實作了好用的版本管理系統,我想我多半會把他加回去吧?當作加值功能之類的。反正順便囉。

        刪除
      21. 維基百科是維基百科,它要考量多人協作的穩定性與安全性,它必須鉅細靡遺、絕無漏版,但筆記軟體沒有。

        要像維基百科一樣,您早就該為每則筆記及每個 section 全部提供流水帳似的版本記錄了──但嫌它一堆垃圾、不好用、佔空間的不也是您自己嗎?


        我個人預計,「語意上的 section」很少有版本管理需求,果真有,那八成應該獨立為另一則筆記頁。如果有人會搞「旅遊計劃main」、「旅遊計劃中國版1」、「旅遊計劃中國版2」、「旅遊計劃中國版3」、「旅遊計劃日本版1」、「旅遊計劃日本版2」、「旅遊計劃日本版3」、「旅遊計劃美國版1」、「旅遊計劃美國版2」、……,我會認為這些比較像是「語意上的 section」,全部都可能之後有同時使用和改寫的需求,那本來就是 section。

        好啦,我承認有些人真的會連「旅遊計劃中國版1」都要搞版本記錄……但這並不難辦,比如在筆記頁「旅遊計劃」中使用這些 section(s):main、中國版1、中國版2、中國版3、日本版1、日本版2、美國版1、美國版2、~20140715112345 main、~20140715112355 中國版1、~20140715122355 中國版2、~20140715153412 中國版2、~20140715153412 日本版2、……,總之毛毛蟲一律是版本,其他通通當語意就是。

        (倒是有兩件事可以考慮,其一是毛毛蟲在 UTF-8 排序上不是那麼理想,它會在英數後面,但在中文前面。如要明確的置前,驚歎號可能會更好;如要置後,可能要找 UTF-8 之中最後一個碼位,而兩者都沒有 archive 的意思。其二是舊版本通常會封存並禁止編輯,但毛毛蟲 section 不會如此,這可能讓使用者不小心誤改了應該要固定下來的版本記錄,可以考慮添加鎖定、設唯讀之類的功能,否則就提醒使用者小心吧。)


        至於比對,我認為不必畫地在「版本比對」,想成咱提供的是「文件比對」就好。

        人家 M$ Office、 LibreOffice 、 WinMerge 等軟體都是讓使用者任選兩個文件比對的。我想,提供「某頁面某 section 的兩個歷史版本」的比對和提供「任二頁面」「任一頁面的兩個 section」或「任一頁面 section 的兩個版本」的比對在技術上應無太大差別(後者恐怕還難些),況且文件比對不會咬人,既然如此,給使用者越多自由越好,畢竟您覺得不實用,其他人未必覺得啊……。

        還有,您知道維基百科可以比對「主頁和 talk 頁」或「兩個不同頁面」嗎?這裡有飯粒: 12

        實務上自然不常用,但這也非絕對無用──如果某爭議君把 A 頁面的許多內容 copy 到 B 頁面上去,追查時不就有「比對 A 頁面 X 版本與 B 頁面 Y 版本」的需求了嗎──維基百科如此,筆記難道不會有 copy 來 copy 去的機會?

        刪除
      22. XD……

        這個嘛,咱們一開始聊起「鉅細靡遺絕不刪除」之版本紀錄,還有「維基百科的版本管理是憧憬」的不是您嗎?我們的立場什麼時候反過來了。(大笑)

        關於版本紀錄佔空間這件事,這正是我前面不斷強調說「無用版本要被回收」的原因。因為我只打算保留「確實有保留價值的版本」。(目前的想法中,「確實有價值的版本」是由「過期時間」與「有語義訊息」兩者來定義)

        我認為,如果是為了保存有價值的版本,付出空間作為代價並不能算是浪費。消耗空間不是壞事,無意義的浪費才是。再說,就個別 Section 分開做紀錄這點來說,如果用戶不想記錄版本,那也不會產生額外的紀錄,長期說來也不會消耗更多空間。

        至於你問我之前嫌棄大量紀錄版本的原因?那是因為我那時還沒有想到如今這樣能「自然淘汰」舊版本的方法,所以對大肆紀錄非常忌諱(因為被咬過),不過既然我現在想到可用的回收規則,那麼大量記錄版本也就不成問題(雖說需要一些但書,比方說不能用 VCS 實作等)。

        原來維基百科可以 talk 與內容頁比對,我一直沒注意到,受教了,感謝糾錯。

        關於 Section 與其他 Section 進行比對,我懂你的意思,您認為有這種彈性也沒啥不好。但事實上「不好」是存在的。額外的編碼量,更多的例外事項,對用戶來說模稜兩可的概念等都是。

        此外,我不認為筆記軟體需要「文件比對」也是一個致命傷,我對此沒有憧憬,也就無從想像怎樣實作才會好用,而且也沒動力去做。您得舉出更多用例才能打動我。

        以我目前的想法,「版本比對」已經踩在「功能蔓延」的邊界上,我甚至還不確定會不會實作它,而「文件比對」顯然更上一層樓。我必須控制這種蔓延狀況(記得我當初連程式碼高亮功能都給拔掉了嗎?就是因為我覺得功能蔓延過度,哪怕我自己就經常寫 code)。除非能舉出非這麼做不可的情況,或這麼做的頻率很高,或有這種需求的人很多,或這麼做有什麼大到讓他值得被「內建」的好處,那才能另當別論。

        至於您提到的某爭議君的用例,以及「文件比較」能發揮的效果,我是這樣想的……

        1. 某個 Section 中消失了某部份內容,而另一個 Section 中增加了某部份內容,有人推測這兩個 Section 之間有著互相剪貼的關係,且剪貼過程中,被懷疑涉及修改與破壞行為,需要「內建」一套機制來處理這種狀況……我想這情況有點太過偏門了。如果有這餘力,把精力用來設計表格處理函式庫、中文字數計數器都更加實用。

        2. 就算惡質行為發生,版本紀錄也已經足以應付--甚至不用進行「版本比對」就能處理這些狀況,有比對也只是額外的錦上添花。

        3. 對於有「巨大差異」的兩個版本 (如兩個不同用途的 Section),我們都知道版本比對的效果一向不好,就算做了也很難真正派上用場。

        我覺得版本比對這類功能可以做,也不難做,但那是非常次要的功能,只要它影響到程式碼的可維護性,或是可能讓使用者感到概念不清晰或不容易用,我就會將這件事緩一緩,直到我想到能讓我滿意的方法……或是我感到到這功能重要到我再也按耐不住為止。

        刪除
      23. 呃…本人很開放的,當初雖說「看起來寫作草稿有個持續的版本記錄功能還不錯」,但我也很清楚我「不知道實際用起來會不會有什麼大問題」,所以找個有相關實踐經驗的人談談這樣,為了只是更加瞭解(以及評估自己要怎麼做)。


        咱換個討論方式吧,您轉換到 Lonote 3.* 也為時不短了,實際使用 section 後,您自認有沒有比以前的版本管理系統更方便呢?
        使用 Lonote 3.* 以來您是否曾在任何情境下因缺乏真正的筆記版本管理系統而感到不便呢?能否具體談談那些情境呢?
        順便問件一直很好奇的事──之前 Lonote 1.* 2.* 留下來的大量版本,在您轉換跑道後,您是怎麼處理它們的?


        這裡試圖主張的不是「把版本管理系統和 section 合體會更完美」──我相信真正的版本記錄實作肯定會更完美,您提出的自動、手動、及依時間和語義清掉雜訊看起來也非常好──只是我看不出也想不出 for what ...其實經歷這段討論後,我感覺筆記似乎不需要那麼精緻的版本管理,甚至草稿似乎也只要前面提的改良版 section (或搭配 Dropbox & GD)就能應付,畢竟很多草稿其實發布後也不知留著幹麻,保留那些版本好像也只是為了紀念 XD

        自行開發及維護版本記錄系統是很大的工程,好像…應該有個相應的效益吧?大費周章實作個版本記錄系統,是為了照顧哪些實際需求呢?哪些現有的 section 系統或其簡單改良(eg. 自動複製、自動填入毛毛蟲時間戳)還無法解決或只能解決得差強人意的需求呢?

        借用您的台詞:「版本管理機制」是不是「功能蔓延」呢?

        刪除
      24. 嗚哇,我們的立場真的反過來了。不過這樣很好!表示我們都在進步。

        回答您的問題:

        LoNote 3 的 Section 不是版本管理--儘管他可以應付版本管理需求,但他本身不是版本管理系統。他是一個具有通用性的系統。單就版本管理這塊來說,Section 系統並沒有比舊有的版本管理系統更好用,主要在於 Section 新建的手續較麻煩。

        不過用了這一陣子後,我覺得版本管理可以的話還是應該要獨立出來,本來只是想著,但因為沒有好方法所以仍在擱置狀態。但隨著與您討論方法浮現出來之後,我覺得可以具體實作。

        回顧一下歷史,LoNote 從最早期的 0.X 時代就有版本記錄功能,那時是用現有的 VCS 實作的,也因此深刻地體會到 VCS 不適合用在這種地方,過程中被咬得很痛。

        0.X 升級到 1.X 時,我沒有讓用戶轉移版本,而是直接把版本放棄掉。因為一來當時用戶數量很少,二來那些資料很難轉移,三來我最初開發 0.X 時代缺乏經驗,根本就沒有考慮過後續維護與資料轉移的問題,當時使用 VCS 對我來說是一種失控,我對此缺乏轉移的概念與能力。

        然而我依然很重視版本管理。版本管理做不好,是我心中的一個大疙瘩。1.X 時代,我決定把現有 VCS 拋掉,自己搞一個版本管理系統出來(沒錯我已經搞過了),這次的基本原則是「自動儲存版本優先,但也支援手動儲存版本」。而在開發這套系統的過程中,我搞出了很多的意外。

        比方說,我最初把預設的自動版本記錄周期設為一分鐘一次,然而隨著開發,這個預設時間逐漸增加,五分鐘、十分鐘、半小時……最後我發現比較適合的預設紀錄周期應該是每 12 小時有變化則記錄一次,不然紀錄量實在太多。

        此外,我發現版本之間往往差異太小,系統老紀錄些芝麻綠豆的瑣碎資料,因此無謂增加無用版本……為了這種事,此我導入了計算兩個版本差距然後得到「差異量」,當差異量高到某種程度時才自動記錄的算法(用戶可設定想要的差異量,比方說兩百字元),使得自動紀錄時版本與版本間的差異能受控制地拉大。然而這個算法相當花費時間,為此我不得不導入多進程支援。

        因為自動記錄量還是太大,我也開始試著減少紀錄消耗空間,為此我實作了增量編碼的壓縮系統。而增量編碼還涉及如何計算基礎版本,以及疊加版本數量如何不要過多的問題(以免每次想取回一個舊檔案,就要遞迴讀取它的基礎版本、基礎版本的基礎版本、基礎版本的基礎版本的基礎版本……進行太多層的增量運算)。

        還有更多:如何讓用戶管理舊版本?如何將舊版本拿出來用?如何讓用戶刪除指定版本?--涉及增量編碼後,因為版本與其他版本產生了關聯,刪除個別版本這種操作變得極其麻煩而且十分脆弱。且增量壓縮後,用戶也無法用編輯器直接讀取資料了,這件事同樣讓我很頭痛。此外,我在 1.X 中還遇過像是「復原了舊版本,但現在編輯版本因此被蓋過,使現在編輯版本丟失」這種大意外……我在慘痛經驗下學會了必須要把「現在編輯版本」也視為版本庫(臨時的)一部份,切換版本之後才能再次將其喚回。

        我甚至也在 1.X 中實作了版本比對功能。那時用的不是 HTML 版本比對,而是先將 HTML 重整為標準格式的 TXT,然後再對兩者做 diff。因為現有的幾種的 HTML 轉 TXT 程式都會損失某些重要格式,我參考了一些人的作品後,親手實作了 parser,比對效果也還可以。

        可以說,除了版本路徑不能分岔以外,能想到的我都做了,能踩的地雷也都大腳踩下去了。

        這充份驗證了何謂第二系統效應 XD

        正如您聽到的那樣,我很重視這一塊,並將其直接視為 LoNote 的核心功能之一。就像您對版本管理有憧憬一樣,我在這方面的憧憬並不輸於您,事實上我早就按耐不住掉坑裡去了!毋庸置疑……

        然而正因為我如此熱衷,我也發現了之前和您提過的各大問題點:大量的版本數量造成大量的空間消耗,而為了縮減空間消耗,反過來引入的技術如增量編碼、壓縮、刪除版本、多進程、版本差異分析……這都造成大量的編碼困難與概念不清晰,以及脆弱的系統等。

        而付出了這許多高昂的代價,1.X 紀錄下來的版本依然很難使用。因為「自動記錄經常斷在文意不完整的地方」、因為「記錄缺乏語義訊息」、因為「自動紀錄與手動記錄混在一起無法區分」、因為「紀錄列表項目數量太龐大」讓人腦無法篩選……

        請注意上面的眾多問題,這些問題的根源,我當時的我,認為問題出在「自動紀錄」上面。

        所以 2.X 計劃開始了!

        1.X 的版本資料可以被轉移到 2.X,不過我覺得那堆資料龐大到用戶難以處理,又沒啥用,故轉換程式預設設定是不轉移的,用戶想轉移版本紀錄要開個額外選項--總之,如果用戶很在乎那堆記錄自然會勾,忘記勾應該也會立刻發現記錄怎麼不見了,不在乎的話大概也不會注意到。如此版本庫大小自然也就大幅縮小了,幫用戶把包袱拋掉。

        為了避免再次被大量版本淹沒,在 2.X 版中,我決定把「自動版本紀錄」功能拿掉(有例外:預設 90 天內容長期不改變則自動記錄一次,藉此追蹤何謂「穩定版」)。用戶可以任意紀錄版本,但全靠手動紀錄,而且一定要輸入語義訊息,以確保版本記錄確實是有意義的。

        2.X 的版本紀錄沒有像 1.X 那樣造成問題,但老實說也沒啥亮點。技術方面,主要就是我研究出了 HTML diff 功能,不過即使有著這功能,我發現我也很少去用。

        此外,我也注意到我不太常去動手記錄版本,這大概是因為每次記錄時都要想語義訊息,操作起來總覺得很繁瑣的緣故?再者,如果只是臨時記錄一下,除非事後記得手動刪除,否則無謂的臨時紀錄還是會增加。需要付出額外功夫管理,光想就累了,因此也不會做些臨時紀錄。總之就是麻煩……

        而且,這種版本紀錄概念也無法解決某些問題,像是「剪截小片段」等,這些問題我在 Section 推廣文裡提過,此處不重複。

        發現版本記錄使用頻率很低,我在 LoNote 3.X 中決定替原有的版本紀錄系統擴充一些運用範圍--而這結果,就是能同時應對版本紀錄與額外頁面的 Section 系統(註:2.X 資料轉 3.X 時,我直接把 2.X 的版本記錄轉到 3.X 的 Section 去了)。雖然 Section 對純版本記錄來說不算很好用,也不乾淨(因為內容可修改,不能真的算是記錄下了「舊版本」),但基於我用 2.X 的經驗,我相信版本紀錄數量本來就多不起來,故問題也不大。

        雖然我依然覺得缺了些什麼?有什麼地方不理想,但我又想不出到底是哪裡不對。

        事實上,直到這時為止,我都認為版本記錄數量很少,是自然、必要又沒辦法的事情。至於「大量記錄同時大量回收」這種概念,我壓根沒想過--版本記錄應該是神聖的!用戶決定要回收也就算了,讓電腦自己決定要不要回收?簡直荒謬!

        ……如此這般,我根本就沒深入去思考這些細節。直到咱們聊起來為止。

        至於您說 for what?嗯,我沒法很直接地回答您,不過看過前面一堆充滿血淚的描述,我想您應該能理解,我是將「紀錄舊版本」與「取回舊版本」這兩件事,視為 LoNote 的核心功能之一。之所以演進到如今的樣貌,並非因為我覺得它不重要,僅僅是因為我百般嘗試後,卻依然找不到合理、無負擔又確實能發揮效用的實作方法。

        反過來說,只要有方法,我是很樂意衝去做的。

        刪除
      25. 您沒有回答真正的問題……

        『為什麼要把「紀錄舊版本」與「取回舊版本」這兩件事,視為 LoNote 的核心功能之一?』
        for what?
        為了您個人的成就感?因為實做出一個酷炫功能很屌?
        ……不是吧?

        筆記軟體的最終目的不就是方便好用、滿足重要的日常需求嗎?
        「有用」的真正定義應該是滿足了重要的需求,而不是只要「記錄了用戶確實想記錄的版本」、「不會留下一堆根本不想看的雜訊」就表示版本管理系統「有用」。
        因為很多時候這些「用戶確實想記錄的版本」最後也根本沒用到過,因為其實不用版本管理系統也有很多方法可以記下「用戶確實想記錄的版本」。

        所以我問您個人的經驗,您從 0.* => 1.* => 2.* => 3.* 以來,您自己建立的版本庫怎麼了?
        您說 1.* => 2.* 可以選擇要不要轉移版本庫,您自已轉移了嗎?
        您說 2.* => 3.* 會把版本自動轉成 section,您自己後來怎麼對待這些 section 呢?留著原封不動?或是一個一個改寫、甚至刪除?

        所以我問您,您使用 Lonote 3.* 以來,有沒有什麼情境或場合讓您真心覺得:「唉,這時候要是有實做版本管理系統就好了」?

        您不必說服我,但如果您一項也想不出,在下以為您真的要好好問自己了:『把「紀錄舊版本」與「取回舊版本」這兩件事,視為 LoNote 的核心功能之一』有意義嗎?

        刪除
      26. 補充點個人對版本管理系統的心得……

        版本管理系統有什麼用?


        對於程式寫作者來說,只要程式碼稍有不同,運作起來結果是千差萬別。VCS 之所以好用是因為可以隨時總覽之前改過了什麼,可以隨時比較任兩個版本全部的程式碼有哪些差別,可以隨時切換到任一版本,可以把某個分支的很多修改直接合併到另一個分支上

        => 但這些都不是 Lonote 要實做的功能。


        對於一般使用者來說, Dropbox 的自動化版本管理之所以好用,是因為他們再也不用擔心不小心把檔案存壞或改壞,因為他們隨時可以還原回之前的版本

        => 這好像是 Lonote 考慮實做的部分,但不用複雜的版本管理系統,只要叫用戶把資料庫放在 Dropbox 裡,或者只要實做運行時儲存一個暫存版本即可。


        對於寫作擬稿來說,(Media)Wiki 之所以好用,是因為它提供非常便捷的版本切換及比對界面,我可以很方便地切換到另一版本,也可以很方便地比較任兩個版本有何差異,進而調整改進目前的版本。如此一來我修稿時可以盡情發揮、想改就改,可以天馬行空、揮灑創意,而不是每次都考慮這樣改會不會更好、要不要先建立一個備份,心理負擔少很多。

        => 但您不想提供版本比對。
        => 而且,就算提供了版本比對, wiki 的 raw text 比對和 html source 比對的效果千差萬別
        => 而且,即使提供像 Lonote 2.* 的 HTML 比對,我還是不太滿意。我看到的是 line level diff,但寫作稿的差異比對要 word level diff 或 char level diff 才有實用價值(中文維基百科有 char level diff,雖然不是 HTML)。您知道的,一行中文可長達百字,沒有這等級的 diff 是要找到眼睛脫窗嗎?
        => 而且,即使有良好的 char level diff , Lonote 2.* 的版本比對機制也不保證 html 附件正確記錄和還原...


        至於其他場合?抱歉,我想不出來了。

        一般文件 copy 改檔名加前後綴就好,版本比對系統記錄了還要繁瑣地匯出、比對,不如直接拿兩個檔案比對快速。(拿去現實世界向人宣傳版本比對,得到的大多是這種回覆)

        筆記 copy 或建 section 貼上備份內容就好,甚至如您所說的,建立一個「剪貼簿」 section 把想廢棄的段落、神來一筆但還不知道放在哪裡的佳句等等丟進去就好,比起逐版本備份、事後逐版本回溯、比對,這一個剪貼簿 section 可能更好用、更能發揮生產力。


        就我個人的經驗,版本比對是先於版本記錄的。即使有記錄語意,實際要利用一個版本,還是需要比對。想像我的版本記錄寫著摘要「去除情緒化用詞」「潤飾關於XX之描述之前的備份」之類的,我如不比對,能真正知道那兩個版本和目前內容差在哪裡、是我可以參考的嗎?

        要沒有良好的比對功能,記下再多版本,即使記錄了該版本的意義,也大多是不實用的雞肋。


        所以,很遺憾的,您目前提出的草案,個人主觀上不甚看好,看起來並不實用;或者,不會比現有系統或現有系統的其他微幅改良方案更實用(比如之前提到的:自動填入 timestamp、複製目前頁面內容、鎖定 section 禁止編輯、等等)。

        刪除
      27. 我沒有遇過「非(正式的)版本管理不行」的狀況,但我經常覺得「這工具似乎不太好用」,「似乎哪裡缺了什麼」。

        大部份的時候,我會忍耐,我會忘記。但是同樣的情緒浮現太多次,我會開始不滿。而不滿是變革的動力。



        在汽車發明之前,你問一個用戶說他要什麼,他也說不上來,他或許會說他想要一匹跑很快的馬。直到他看到汽車,大叫說「那就是我想要的」為止!

        我知道我需要某種東西,我經常感到不足,為此我花了大量精力時間去做研究做實驗,我經常走岔了路,或是不小心生產出沒裝變速箱的車;這讓我覺得車根本不實用,沮喪了好一陣,或許又放棄車輛跑回去搭馬車。

        但那股需求並沒有消失。雖然我甚至都不確定我要什麼,頂多只有一個模糊的方向,告訴我:「這東西應該有哪裡還能更好」,讓我抓耳掏腮,急不可耐。



        你問我「真的需要版本管理嗎?」,其實我沒有像您想得那麼肯定,我不太確定,但是我知道我手頭上的東西有所欠缺,不完全切合我的需求,而且經常--相當頻繁地--讓我感覺困擾。就像右手手指少了兩根那樣。

        我想要知道為什麼,並且把他解決掉。

        以目前的經驗看來,我認為我要的應該是某種類似於版本管理的東西。我在想方設法去做實驗,接近那個目標。雖然我不確定目標或手段對不對,但我至少可以試試看。

        我最初之所以寫這個程式,正是因為我原本使用的一大堆軟體,全都湊不齊我想要的功能,所以我才跳出來做。我想要把它儘量做好--此處的好,您或許不理解,甚至不認同(就像您覺得文件比對好處多多,而我則覺得它缺點比較多,甚至可能是扣分項)。我說這話並沒有要強迫您接受我價值觀的意思。您可以想像,您對筆記的理想,大概也不會等於您祖母對筆記的理想……差異也就只是如此罷了。



        我想我沒法用「您能接受」的理由回答您,我為什麼會想要「版本管理」這玩意兒。但我可以提供我的理由,這包括但不限於以下幾點:我天生膽小,有個版本管理比較心安,而我相信有些人和我有相同需求;因為完美主義者,只有看到舊版本條列在那裡才覺得「完滿」;因為我過去幾次想要保存舊有版本,卻始終覺得沒有一套通用的儲存方法可收納舊版本,以便隨時找回,故對於標準化的舊版本存放方案十分敏感介意。另一方面,我也認為,我願意承受它所引入的額外複雜度作為代價(雖然我之前幾次判斷錯誤,但我也在不斷調適作法)。

        「設定目標」是程式作者的權利也是義務,而也正是這些「偏好」,讓軟體擁有獨特的靈魂。就像 Keepnote、Evernote、Tomboy、維基百科,甚至紙本筆記一樣,他們各有他們的特色。雖然用戶總會抱怨,抱怨說維基百科編輯器超難用、抱怨說 Tomboy 沒有樹狀結構,抱怨說 LoNote 沒有 Tag 分類功能,抱怨 DokuWiki 不用資料庫很慢又肥,或是抱怨紙本筆記無法搜尋等等。但那都是取捨。

        用戶畢竟有選擇權,可以選擇他們所需要的。

        您當然可以質疑某「核心功能」為啥重要,但這就和您質疑我「現有的筆記軟體這麼多,幹嘛不用一個現成的」一樣,我能回答您某些原因,但您未必能認同它夠重要(換個角度看,會爭執筆記或草稿版本問題的我們,對正常人來說都算怪胎了)。當然,我也相信以各自的立場作為基礎做出評論,是討論初期無可奈何的事情,因此我並不會覺得被冒犯,也希望您不會覺得被我冒犯到。



        還有,如果我讓您誤解的話,我很抱歉,但我真的沒有要說服您的意思。我只是很感激您對我的幫助(特別是觀念上的釐清),覺得應該要儘量認真地回覆您而已。



        順便一提:我看到了您的新用例了,這正是我想知道的,有這種用例我才能釐清您的實際需求。對我有很大的幫助。就算我不會馬上接受,聽過之後總能增廣見聞,這也是瞭解您問題的第一步。

        (雖然說您的需求顯然和我不同……比方說,我從不在原始碼以外的場合進行版本比對;而且我也不是沒試過才這麼說,我已經嘗試過好幾次了,依然覺得它幫不上我的忙。不過當然啦,我是懷疑論者嘛,或許我用了更好的工具後會迅速改變看法……雖然短時間內似乎沒啥指望)

        這麼看來,我所憧憬的嶄新 LoNote,至少在版本管理方面,對您來說,並不會比現有的系統更好。還沒開始開發就慘遭痛擊,真讓人沮喪,不過,也沒辦法嘛。對嗎?



        儘管我無法完美達成您的需求,但您可以自由的 fork 或開發您自己的軟體。像 LoNote 也是我向 Keepnote 的軟體作者提供建議但不被接受後,才動手開發的東西。如果這種「沒人做?讓我來!」的模式能持續下去的話,就算追逐的方向不同,我也會非常高興,或許我們還可以互相參考?

        刪除
      28. 1. 唔...我完全無法理解不用比對要怎麼利用版本記錄,能說說您以前通常怎麼利用舊版本記錄嗎?(當然是指程設以外的場合)


        2. 就我初步看到的:『我天生膽小,有個版本管理比較心安,而我相信有些人和我有相同需求』『因為完美主義者,只有看到舊版本條列在那裡才覺得「完滿」』『因為我過去幾次想要保存舊有版本,卻始終覺得沒有一套通用的儲存方法可收納舊版本,以便隨時找回,故對於標準化的舊版本存放方案十分敏感介意』

        大哥,這之中哪項不是建筆記副本或建 section 複本可以解決的事啊?不是說殺雞焉用牛刀嗎XDD

        如果您只能談到這樣,我不免懷疑自行開發版本管理系統的堅持只是莫須有的執著哦XDD


        3. 算我雞婆吧,建議您在開工前做點多元的測試和評估:

        (1) 試試是否有其他簡單方法能達成需求:比如我說的增加「歷史化 section」的功能,讓用戶能用和建立新 section 幾乎相同的方式建立一個適合存放歷史記錄的 section。由於是在現有架構上擴充,應該很快就能做出來並進入實際使用、評估階段。

        (2) 確認您要的版本管理系統有哪些特性:從前面的討論中,您應該看得出來我不是反對版本管理,只是我認為版本管理要做就要做得非常好(而那是大工程,咱這種小咖還是少碰為妙),而您打算採行的實作方向個人並不看好。

        Lonote 2.* 雖然實做了很多設計,但老實說個人用起來並不順手,理由大致包括:
        a. 沒有 char level diff
        b. 不能快速地跳著檢視前一版/後一版,或「前一版/後一版與目前檢視版本之差異」
        c. 不能快速方便地選擇任二版本比對
        d. 就筆記管理的角度來看,最好能輕易地選擇很多版本一次刪除,或者一次修改多個版本的摘要並一起儲存

        也許您可以試著切回 Lonote 1.* 或 2.* 的開發線去補上這些功能,確認有這些功能後是否方便好用、能滿足自己的需求;或者更簡單地,架個 MediaWiki 或 DokuWiki 實際去寫些東西看看。

        先認清需求再做,也許可以減少不必要的虛擲光陰哦XD


        4. 您應該很清楚我現在主打的是 SrapBook X,其原始版本 ScrapBook 本來不是筆記軟體,它主打的是網頁擷取功能,但我非常欣賞其組織資料的方式和多種貼心的設計(Lonote 很多觀念在早期版本的 ScrapBook 上就有實做了),而內建的註解和編輯功能也頗有擴充潛力,所以就在這基礎上進一步發展為筆記、資料整理軟體。

        既然都這麼做了,Lonote 當然不是我打算直接使用的,而是一個研究對象。這之中有很多考量,比如我不太接受架伺服器的方案(雖然現在也有點猶豫和反覆,因為我也有手機和平板的需求)、以及歷史包袱(也聊聊我的資料量吧:從大約 2004 年我開始使用 Fx 至今,總共抓了約 2300 個網頁,總空間約 1.5GB,總檔案數約 92000,總資料夾數約 2400。這其中有部分原因是小時候不懂事都整頁抓,但估計即使厲行清理,還是有 1/4 ~ 1/3 的檔案/多媒體要保留。但 anyway 這些資料根本無法原貌匯入 Lonote 並維持可編輯可索引的狀態)

        在和您閒聊的過程,我也一邊在實做或修改實做方向,無論如何我參(chao)考(xi)了非常多 Lonote 的設計理念,所以還是非常感激您的。

        刪除
      29. 哦對對對,不小心就忘了您是 SrapBook X 的設計者,失敬失敬。



        1. 怎麼利用舊版本記錄?

        其實前面已經稍微透露了。我真正想要保留的長期性舊版本紀錄,大概都像是「初稿完成」、「第二段大改寫前」、「XX 出版社投稿前校對完畢」、「第二次重製版完成」、「2014 年校對完成」等,語義很明顯的版本。

        因為語意明確的緣故,我運用舊版本時並不依賴版本比對。比方說雜誌社和我討論我的作品時,我可能就把「投稿版」拿出來參考這樣;或是覺得「舊設定」中好像寫了什麼有用的,就拿出來翻看。

        我不在乎某幾個字的細微差異,畢竟這與程式不同,不是幾個字不同就動不了。但我會大量用版本管理訂出工作的階段性。



        2. 這哪項不是建筆記副本或建 section 複本可以解決的事啊?

        您說的對,筆記副本與 Section 副本都能解決這些問題,但都解決得都不漂亮、不順手、不優雅。

        如果以筆記副本紀錄版本,那會汙染目錄樹,使目錄樹大小膨脹,而且目錄的內容語義不明確--目錄中有些是單獨頁面,有些是其他頁面的不同版本。兩者會混在一起。

        用 Section 記錄版本也有類似的問題。明明是完整的舊版記錄,卻和「引用頁」、「精華收錄頁」、「疑點頁」混在一起……這並不清晰。

        您可以注意到,我一直很在乎語義清晰這件事。當然您不需要同意我啦。

        當然,沒辦法時這樣弄也不是不行(比方說現在的 LoNote 3 就以 Section 作為版本的容器),只是如果能獨立出來當然更好,我的筆記倉庫中就有以這兩種東西進行的版本記錄,老實說我每次看到都覺得很噁心,想要除之而後快。

        我具體的希望是:平常我看不到那些版本,也不想看到他們,我不想在那些東西上面分散注意力,版本紀錄根本不要出現在我面前,最好就像不存在一樣。然而一旦我要找它,它就在那裡。我不用大費周張翻資料夾、篩目錄樹、尋找好幾個可能的地方。他就在「那裡」,排列得好好的,沒有例外。這就是理想狀況。



        3. ……(過長不錄)

        我也覺得 LoNote 2 不好用,所以才會開發 LoNote 3。如果我又對 LoNote 3 不滿了,恐怕也不會甘願退回到 LoNote 2 去。其實我每次換主版本號,幾乎都是是因為想要大改架構,過程都會替換掉 70 % 以上的程式碼,重寫幾乎全部的組件。切回去寫舊版挺頭疼的,而且明明是自己知道為啥捨棄的架構,繼續在上面添磚加瓦實在受不了。

        順便聊聊您提到的問題,LoNote 2 沒有多頁整批刪除的功能,確實如您所說非常正確。不過如前所述,我想要紀錄的版本都擁有語義,所以在我的想定中,這種版本數量不會多,而且也不會在短時間內密集地加個不停(指當時的想法),而且多半也是要長期保留的,所以當初根本沒有考慮大量刪除的問題。

        事實上,最初我開發時,取捨的兩造反而是「要不要提供刪除功能」這件事……蠻意外的吧?

        而為什麼版本比對無法滿足您的需求,看過我的用例後您應該也能理解了--雖然我覺得有比對很好,但以我的用例來說根本用不到,只是好奇做做看,看效果如何,難不難做而已。(然後我就把他踢掉了)

        其實早就該把用例拿出來了……難怪張飛岳飛嚕了這麼久。

        您的用例呢?看起來您大量剪輯網頁對嗎?自己生產內容的比例是多少呢?大概都紀錄些什麼東西。不介意請分享一下,我的資源檔案數量不多,蠻難想像 1.5G 是怎樣搞出來的。

        最後再補一個個人的想法。您說:「版本管理要做就要做得非常好」不過,我的想法是,系統能解決問題那就夠了。全功能的電腦自然是不錯啦,不過一台 Respberry 也有一般電腦無法提供的好處嘛,像超低耗電量之類的。只要別拿它去做超出設計範圍外的工作,這些系統可以很優雅地解決問題,甚至能做得比全功能的系統更好。

        Mediawiki 我架過囉,不過那又是另一個慘烈的記憶,想到就辛酸,等有空再說吧。

        刪除
      30. 1. 看來咱們習慣很不同呢XD

        我也是會記錄「初稿完成」、「第二段大改寫前」、或者「發布一版」、「發布二版」之類的舊版本,但我想參考舊版本時,第一個想到的是先用比對的方式找出X版和目前版本有哪些段落不同、差了哪些字,一比完就知道這版本有沒有參考價值,我要讀一讀還是跳下一個版本參考之類的。

        總之即使是差不多的用途,我還是很難想像不比對的情況。


        2. 我同筆記副本有這些缺點,就不多談。

        但您談及 section 副本的缺點,我懷疑這只是現有架構的不足而已。

        比如我提過可以實作「版本式 section」(最近想了想有一點改變),具體上來說就是在新建 section 按鈕旁邊加一個「建立備份 section」的按鈕,它和新建 section 的行為只有幾個微小差別:
        (1) 會把當前 section 的內容複製過去
        (2) 不同的命名規則,比如如果目前 section 是 main,產生的 section 會是 .main.20140716220212 之類的(或者 .main.1, .main.2, ...)

        上述做法是用 Linux 系統的隱藏檔前綴來區隔一般 section 和備份 section,然後我們可以實做更多行為的不同:
        (1) 瀏覽 section 列表時,加個勾勾選擇是否列出「隱藏檔」
        (2) 搜尋時可決定要不要搜「隱藏檔」
        (3) 如果現在瀏覽的頁面是「隱藏檔」,則禁止編輯(或者柔和一點的,不自動進入編輯模式,但允許 F10 手動切換)

        這樣和您想要的「有語義的版本記錄」應該差不多順手好用了吧?


        3. 我的用例都說過啦XD

        如果是在 wiki 寫稿,我的用法就是盡管寫,寫到高興就提交,寫到有點混亂就回頭比對舊版來調整新版。但這是在「有良好的切換版本及版本比對」的前提下。

        如果是一般電子筆記,我很少做版本管理(也沒得做),但的確也會有覺得舊版刪了可惜但又不想當一般筆記留著的情況,以前的做法是就留著或搬到另一個筆記本或 tag 起來。現在可能會用 section 的處理方式,即使沒有備份 section 系統,建個「2008-02 1版」、「2009-01 2版」放進去,我覺得就夠用了。反正總數不多,我覺得這種「舊版備分」和其他「靈感小記」、「試寫廢稿」之類的 section 列在一起也沒不方便到哪去。

        (P.S:我不是真的用 Lonote,而是用 ScrapBook X 上實做的類似功能。ScrapBook X 可以建立「筆記頁面」,然後可以用 Alt+I 插入子頁面,再把內容複製進去;另一個方式是用「顯示相關檔案」打開該筆記頁面的資料夾,手工 copy index.html 改成另一個檔名。我後來也實做了複製目前頁面的功能,但目前還沒發布。)

        然後,之所以剪輯網頁很多是因為那本來就是 ScrapBook 的功能啊XD ......一般記事我是放在 Evernote 的,目前大約有 2450 則筆記,總大小根據 Evernote 的本機資料庫是 370MB (不知道有無壓縮或加料),內容當然是雜七雜八包山包海想到什麼就記什麼,文字為主,偶爾會放點低解析度照片。實做 ScrapBook X 處理筆記,主要是因為 Evernote 實在不適合結構化整理資料和管理知識,才決定把需要架構和組織的內容轉移到 SB 來處理。

        3.5. 您誤會了,我所謂「版本管理要做就要做得非常好」的意思是,如果版本管理沒有非常好,其他替代方案大概就能做得比它更好,相形之下版本管理便沒有必要了,而其中您的 section 就是一個很有競爭力的方案,剩下的請回到 2. 吧。

        刪除
      31. 除了筆記舊版本的留存,我倒是有個更常發生也更感困擾的問題……那就是封存筆記的留存。

        有些筆記是比較任務式的,比如「Lonote 3.2.9 當機問題研究」,這種筆記大概在開發者修掉 BUG 以後就算是任務結束了,但此時要刪掉筆記嗎?

        嗯......不刪可以留著日後瞻仰自己幹過哪些豐功偉業,或者以備不時之需(比如日後 Lonote 可能哪些問題會和它有關),但這種筆記多了,目錄樹將會充斥著一堆已經完成的工作,而這些東西通常是平常不想看到、搜尋時也不想見到的,只希望在有心想查時能查到。

        刪了留垃圾筒但不清理?也不太對,因為垃圾筒主要意義是防誤刪,把封存丟垃圾筒,清理垃圾筒時反而瞻前顧後,不能無所顧忌直接清空......

        建立個封存頁面移進去?但這樣便沒有把原來的位置記錄下來,而且「軟體測試/Lonote/」下的檔案和其他雜七雜八的檔案堆在一起,總感覺怪怪的。如果把原來的路徑也記進去(比如「軟體測試/Lonote/Lonote 3.2.9 當機問題研究」移到「~archive/軟體測試/Lonote/Lonote 3.2.9 當機問題研究」)可能好點,但這麼一來每次刪除都要建立好幾層頁面,操作上頗為不便。此外,這樣做還是會在搜尋時跳出一堆不想看到的封存筆記。

        您會怎麼處理呢?

        刪除
      32. 關於任務性質很強的筆記:這確實是個問題呢,我也有注意到,確實就像您所說的那樣。

        但它其實不太干擾我。因為對這種內容,我通常都是把一堆瑣碎小物集中在同一個筆記頁中,比方說「LoNote 4 開發構想」其中就涉及了底層檔案系統、API 介面、使用函式庫選擇,Meta 進化、資料結構、可實驗的技術等等訊息。我不太把他們拆開,所以干擾也較小。之所以不太拆開,也是因為這種東西本來使用周期就短,集中運用反而方便,而不需要嚴謹地結構化的緣故,而且只用一頁也不用不斷地新建刪除。

        而過期的舊資料,比方說已經過時也沒參考價值的資料(如某些過時的軟體的使用技巧筆記)以及您所說的工作紀錄。當我開始覺得他們會干擾我,讓我覺得煩時,我就會將其匯出封存起來。這些東西都是我覺得「以後絕對不會用」的東西,直接刪掉其實也無彷,匯出封存只是以防萬一而已。



        關於用 Section 記錄版本,您的作法其實也是可以達成目的,而且 Code 也不會比較多;如果我要快速製作一個版本記錄功能,那用您的方法修改現有系統是最快的。

        不過我每次大改版都會改很大,所以我其實不在乎多寫些 code(事實上也不會多多少,儘管我很難告訴您我是怎麼估的),反而更在乎容易維護這件事。而用 Section 正式模擬版本管理的作法涉及一些例外狀況,會增加維護複雜度,這種複雜度甚至會在非版本管理系統的其他地方(如模版中)增加額外編碼數量與程式理解難度。總之,擴充現有功能以應對例外狀況,這種事情很容易失控……嗯,都是些是會讓人 PTSD 發作的慘烈回憶……

        當然啦,或許您不認為我介意的那些很重要,您聽聽就好。

        刪除
      33. 1. 如果有確定「以後絕對不會用」的東西,當然好辦。問題是有太多東西處於「以後絕對不會用」和「以後可能會用到」的邊緣了,難以判斷啊orz

        開發隨想這類東西,全塞一頁的好處如您所說,統一管理、綱舉目張,缺點是不靈活,尤其是想按時序回溯的時候。這種「依意義回顧 vs 依時序回顧」的困難從傳統筆記到現代文件檔,都一直存在者。

        還有一個分散的理由是,每次靈光一閃時,不見得有時間去考慮它位於哪個架構、哪個層次之下──把這些都想清楚靈感就飛了,於是我傾向立刻建一則筆記把當下的想法記下來,以後有空再整理。整理時通常會把很多則靈感小記整合到一個核心筆記裡,然後又要猶豫了:這則「當下靈感記實」要不要刪掉勒?XDD

        * 別刪,因為它是一則記實,有人事時地物的記錄,未來可以更精確地回溯(一如一切版本管理系統之初衷)
        * 刪吧,因為以後 99.99% 不會用到......
        * 封存,要存在哪裡?怎麼存?如何 keep 住原來的結構?如何讓它平常不造成干擾,想找時又好找?
        每次都會困擾這個,很煩啊……

        section 系統看起來可以解決不少問題,比如把這些當下靈感集中到某則筆記的某個 section 中,但還是有一些不足,比如如前所述,靈感跳出來時,往往無暇細想應該擺到哪則筆記下;如果當時是記成一則則獨立筆記,又沒辦法把它變成另一則筆記的 section(可以複製貼上,但無法把建立修改時間等 metadata 保存下來)(←這個也許可以考慮實做?)


        2. 我接受這個理由。您說的「有明確語義及系統中之定位」「程式管理及維護複雜度」「您覺得不會太大費周章」的確可以是考量點。

        我並不打算要您說服我,只是想知道您怎麼說服自己的,現在看到了,那……就暫且如此吧。


        3. mercurial 推抗文勒?俺等著拜讀 & 吐槽呢!可別臨陣脫逃啊!


        刪除
      34. 其實不能算是推坑文,更傾向辯解文,畢竟 Mercurial 被 Git 用戶誤解得蠻嚴重的。Git 用戶多聲音大,許多誤解也就難免因此到處傳播,所以想來平衡一下輿論。至少讓其他用戶在查資料時,有機會聽到更多的聲音與不一樣的著眼點。比方說 Mercurial 的 branch 模型有啥好處是 Git 不具備的,Git 的 branch 模型在 Mercurial 中是如何被解決等。

        當然文章太長,錯誤率也會跟著增加,被吐嘈是必須的。雖然我也用 Git 好一陣子了,不過 Git 的文件畢竟不好讀,對於我提出的問題,可能會有我不知道的解決方案或是密技也說不定。到時就請儘量補充吧。目前有人在幫著整理稿件,就算順利也要等上一兩週,總之請稍等一下。

        原來還有依時序回顧這種用法嗎!?我一直沒這樣用過。除了近期資料與版本記錄以外,我覺得時序並不重要,雖然我有紀錄時間戳,但我從沒用時間索引過他們。或許這也與我們對待「版本管理」系統的觀念有關?我只會在查找舊版本時偶爾檢視時間訊息而已,在一般文章中是不用它的。

        關於臨時頁面方面,我會用「瀏覽器的書籤」標定自己用來堆雜物的那個特定的臨時頁面,不知道該放哪裡的訊息就管他三七二十一先塞進那一頁中。

        如果真是臨時訊息,比方說「下午要去買包子」,那麼用完就刪,完全不手軟。反之如果是像「在某兩個角色之間加點 BL 式曖昧可能不錯」這種東西,則會等有時間把它另行整理到它該放的地方。

        話說一開始省時間亂扔,後來就要多花點時間收拾。這和任何其他類型的整理問題都一樣,我是將「亂丟之後需要整理」視為無法解決的問題。不過,至少我亂扔的東西全集中在一頁中,要整理時只要把那特定的一頁清掃乾淨就行了,不會有漏失,而且隨著頁面越堆愈多,也會逼著自己非清理不可,不至於懶上太久。

        刪除
      35. 居然有人處理稿件,會不會太專業一點啊XDD


        如果您是把所有雜類記事都寫在同一則筆記,之後整理時剪到「該去的地方」,我想對我而言就等價於於刪掉原始筆記了……這是個辦法啦,只是我沒看到很有說服力的理由,且就個人經驗,它確實有相應的缺點。


        「靈感-整理」的說法可能比較抽象,我換個說法好了,假設我去聽一場學術演講,演講有一個主題,但其內容可能和教科書分散的好幾個章節有關。此時演講筆記該怎麼記錄?
        1. 整個演講記成一則筆記,並記下時間、地點、講者
        2. 不管上述那些,當講者講到和教科書第 X 章有關的東西時,就把這些內容加到 X 章的筆記的適當地方;講者接著講到和教科書第 Y 章有關的東西時,就在第 Y 章的筆記的適當地方補上東西;依此類推。

        你會怎麼做呢?我想通常是 1. 吧(畢竟演講中要翻查相關章節有其困難)?但事後整理知識時,一般會把 1. 的內容拆到 2. 的各相關章節去吧?

        但是,整理完以後這則演講筆記就該刪嗎? 2. 的那種分散記錄確實比 1. 這樣一則演講記錄更「好」嗎?我想是很難說的。首先,講的某些內容很可能根本找不到對應的教科書章節,有可能是其他教科書的、甚至其他領域的東西,這些要另外開筆記擺嗎?如果講者講一段和 A 領域有關就加開一則 A 領域筆記,講另一段和 B 領域有關就加開一則 B 領域的筆記,豈非把原來一則完整的筆記搞得更零散、更瑣碎?

        但是不整理嘛...也不見得好,畢竟我們建立知識,多半還是按照學科、教科書和章節去跑的。

        很可能的結果是,我保留 1. 的這種演講筆記,但又把其中某些重點另外整理到按學科章節組織的教科書筆記中。


        對我來說,突發靈感往往就像演講筆記,可能是和具體情境相關(比如與某友人大吵一架後的反思),也可能和某些正在執行的專案(比如某友人提到對某軟體的看法,可能和我在開發的某個軟體的設計有關)或正在研究的某個主題相關(比如大吵一架的反思可能和我正在研究的某個心理學理論有關;友人提到對軟體的看法,又和使用者使用軟體的行為科學研究有關),當然可料想的,也可能前面和X有關,後面卻和Y有關。此時常發生的情況便是,我根本難以決定這則靈感筆記「該去的地方」是哪裡。

        那……就不要整理,維持原狀嗎?

        這又回到之前說的問題了,零散的靈感筆記常常不好用,我們建立知識,多半還是按照學科、教科書和章節去跑的;我們規劃案子,多半還是照著和案子有關的東西去跑的。以前的靈感和反思事後回顧往往會發現是粗糙的、草率的、錯誤的,搜尋時跳出這一堆不成形的東西可不太妙……

        整體來說,我要查找到東西往往可以分成兩類,一種是當查找某些成形的、明確的知識,或者專案的最終規劃。另一種是在規劃或研究階段時,查找所有可能有關的靈感。這其中又有模糊地帶,比如我某時某地對規劃的靈感,該算是零散的靈感呢?或是完整、明確的規劃呢?


        結論嘛......沒有結論,如果我知道,就不用苦惱了。

        刪除
      36. 你的困擾我並沒有辦法提供幫助,而我的意見,大概也無法成為您的參考。因為您面對的是分類的問題,而分類則涉及用途,而用途則因人因事而異。

        我的社會學老師曾經告訴過我,人類替萬事萬物進行分類,究其原因是為了方便。換句話說方便與否就是著眼點,而何謂方便則視於概念的用途。比方說將人類分為尼格羅人與高加索人方便研究種族問題,而將人類分為美國人與加拿大人則適合研究國家差異。沒有必然的分類方法,僅僅只取決於對問題的解決方式是否方便。

        您可以依據課堂將資料打包、或依據知識域來分、或依據難度分類,甚至也可以依據有趣度來分,這都沒問題。就看怎麼用這些資料覺得方便。您甚至可以把筆記當日記一樣按天來寫--如果那就是您的目的的話,也沒啥不好。

        以我個人的考量點來說,我大多時候不在乎資料的時間序,或和現實事件(如某課堂或某本書)的對應關係,我只在乎知識與想法本身,所以我不會依聽了哪場演講,或某些話由誰說的來作為拆分基準。而更傾向於將相關的知識兜組在相鄰的地方,這就是我的通則。不過針對個別事項,我有時也會以有趣度或時間來區分,純粹為了方便。

        至於您說「重新整理轉移資料就是刪除」,這與我的觀念差太大了。總之,我不是很在乎時間戳或 Metadata--這些東西如果能有當然是不錯,就筆記工具的角度也該儘量提供,但作為用戶,被它們束縛住就是另一回事了--我很清楚我想保留的不是那種東西,如果他們礙到我收集與整理知識,我會立刻無視於那些概念把他們通通丟掉,忘到爪哇國去。

        另外,我覺得重寫、重新整理資料以及刪除因為整理而無用的舊資料是件大好事,是將原始資料融會貫通成為知識的最有效方法。一旦我重新整理出更好的版本,我就不再在乎原始那份語意不清文法不通的臨時筆記了。頂多就是作為版本記錄封存起來,讓自己日後覺得厚厚一疊頗有成就感,又或是擔心整理得還不夠徹底或有誤解,讓自己日後留點機會做為存查之用--不過雖然這樣說,事實上真能派上用場的機會幾乎沒有,所以我通常不太在意他們是否一定要被保留(更別說「嚴格遵照原樣保留」),比起保留他們,我反而更不希望他們混在筆記庫裡干擾我日常的查找與工作--我在持續縮減知識中混雜著的雜訊數量。

        整理有助於提高筆記倉庫的價值密度--而私以為,價值密度是很重要的概念。

        一片出產黃金的河灘,黃金的總量可能比銀行的金庫多上百倍,但卻沒有被人利用的價值。精鍊確實代表著損失,但有捨才能有得,我們控制不住超過某個份量以上的知識量,就算做了筆記也一樣。就和我們駕馭不了擁有太多功能的軟體一樣。

        您應該有注意到,以上這些想法和我開發軟體的理念也是相合的。不過,和您的信念恐怕就不是那麼相容了。就隨便看看吧。

        刪除
      37. 「把一大堆資料整理得綱舉目張,然後丟掉」我一直有這種傾向,很長時間也是這麼做的。

        然而,在長期的實踐中,我發現了很多問題:

        1. 如前所述,在聽講的當下,往往無瑕去找出涉及的相關筆記增補之。(當然,我知道您的意思很可能是聽講當下先寫個暫存筆記,事後才整理、寫進相關有組織的地方,然後刪掉暫存)

        2. 我們很容易誤解他人,依自己的方式整理,很可能破壞或脫離了作者的原始脈絡。

        這好比我們可以把《論語》打散,把孔子說過的話分拆到政治學、經濟學、倫理學的教科書或筆記之中,但在此之後,我們能說我們已經破解了《論語》,《論語》這本書再也沒有保留價值了嗎?

        歷史確實是巨大的包袱,因為幾乎沒有什麼東西可以完全被取代。就像寫論文非常講求 reference,哪個觀念出自哪些論文、哪些結論是誰推理出來的、怎麼推理出來的,都要有原始資料可查。能說我的研究已集幾十篇論文之大成,所以留下我的論文就好,那幾十篇論文都沒有存在價值了?

        我當然可以自己整理比如人際相處之道幾條原則,或者簡要經濟學觀念幾條原則,或者筆記軟體應該有的特性幾條原則,但很多時候我也得記下這些原則出自哪本書或哪個人之口,該結論是怎麼來的、推理過程如何等等,以俾事後追溯,因為它們並非不可質疑,也難以確定我沒有誤解誤讀。

        讀書、讀論文是如此,難道演講就不是嗎?

        某個人說了某句話,這話是怎麼來的,有什麼道理或根據,它往往不會講明。我若沒記下是哪個人說的,未來有天我覺得這說法怪怪的,該如何去追溯呢?

        整理個東西要把來源、「證明」過程記清楚,是非常繁瑣累人的,我平常會用的一定是「人際相處之道幾條原則」這類的東西,我應該把它放在筆記之中顯眼、容易查找的地方,以便在想到或需要參考時能最快取得,而且其寫作特性應該簡潔有力,條條簡短、清楚,容易使用,而這和前述的「記清楚」是衝突的。

        3. 目前想到的處理之道是,我還是會整理,而且只抓最重要、最簡潔的關鍵,但留下原始筆記的連結,以俾事後查證。

        「重點摘要、保留原始資料、留下連結供事後回溯」已經是我能想到最簡單又最全面的做法了,不過我還是在實踐中碰到麻煩。

        最明顯的是分類混亂,我很難明確地找到那些「重點、精華」筆記,我猜想這和 Evernote 本身缺乏結構化有關。另一個常見情形是「重點、精華」有很多版本,不知該看哪個好,我想這和 Evernote 缺乏版本記錄或 section 有關,因為如此導致很多試寫稿、廢棄稿、靈光一閃稿很難說刪就刪,結果就是版本林立,一團混亂。

        目前考慮解決之道之一是分流,也就是把需要更結構化、需要更綱舉目張的東西移到 ScrapBook X 來,這之中當然還有些困難,會成功或成仁還不知道…但也只能先試試看囉


        刪除
      38. 「如前所述,在聽講的當下,往往無瑕去找出涉及的相關筆記增補之。(當然,我知道您的意思很可能是聽講當下先寫個暫存筆記,事後才整理、寫進相關有組織的地方,然後刪掉暫存)」

        是的,這正是我的意思,如果臨時沒空去細思分類,暫時隨手一塞之後再整理。這是我習慣的方法。



        「我們很容易誤解他人,依自己的方式整理,很可能破壞或脫離了作者的原始脈絡。」

        是沒錯啦,不過筆記不就是這種東西嗎?--把別人的東西,轉變成自己的知識這樣。某種程度的偏重、扭曲、再理解都是必然的。

        如果以比較寬鬆的心態面對這件事,我們的誤解通常也不會真的很嚴重,通常差異僅僅只是從不同的角度看同一件事情。而另一方面,在知識有被整理過的狀況,就算重點偏離了,只要我們能融會貫通,那也利大於弊。比方說老師上課的主題可能是在講積分,但您注意到老師上課時隨口提出芝諾悖論的哲學意涵,並為此寫了一堆記錄與分析,而把原本應該是重點的積分給忘了--嗯,那又沒什麼關係,甚至比完全按照原意但機械式地抄板書有用多了,而且只有這種經過重新理解的東西,才會真的內化為個人知識。

        我甚至懷疑,如果我們太過尊重原意,我們就不會有熱情,從而學不會任何東西。記錄筆記時破壞別人的原意並無所謂,因為這本來就不是「原文」,而是「我的筆記」。是我的。



        「這好比我們可以把《論語》打散,把孔子說過的話分拆到政治學、經濟學、倫理學的教科書或筆記之中,但在此之後,我們能說我們已經破解了《論語》,《論語》這本書再也沒有保留價值了嗎?」

        這同樣是分類問題囉。

        您在乎的是論語這本書呢?還是論語所蘊含的知識?還是您在乎的是春秋時代的歷史?又或是考試的分數?或是說您都在乎,那麼或許您必須採用更具彈性的分類系統,比方說 Tag 系統;又或是將一份筆記整理多份筆記有著相同內容但不同格式的筆記--聽起還很荒謬,但這不是全是玩笑。針對運用場合的不同,知識所需要的組織型式也不同,私下用來揣摩孔子思想的筆記與對付考試的筆記,雖然主要內容都源自論語,但兩者所需的樣貌會大大不同--唯一缺點就是這樣做會很費勁。

        另一方面,Tag 系統也遠比樹狀系統更難維護,系統中的概念一致性幾乎永遠達不到,我們永遠會漏標某些 Tag,而且還不知道我們漏標了他們,然後在用 Tag 篩選時把他們給忘掉,這是其致命傷。關於 Tag 技術,我現在的感覺是,能用 Tag 來解決的問題,用搜尋來解決幾乎總是比用 Tag 技術更好。

        總之,因為實現層面上有許多麻煩,我不會指望將同一份資料分進多個分類中。分類僅僅只用來解決的是我最關心的問題,如果臨時有其他的分類需求,我會用搜尋來解決。或許您可以參考一下。



        「歷史確實是巨大的包袱,因為幾乎沒有什麼東西可以完全被取代。就像寫論文非常講求 reference,哪個觀念出自哪些論文、哪些結論是誰推理出來的、怎麼推理出來的,都要有原始資料可查。能說我的研究已集幾十篇論文之大成,所以留下我的論文就好,那幾十篇論文都沒有存在價值了?」

        因為您要求完美嘛,所以得為此付出代價(論文是追求完美的好範例,而他的製作成本也相當高)。雖然我也有完美主義傾向,不過我知道這是病,得治--我之前半開玩笑地說過這句,不過我其實是認真的。我會在合理範圍內追求理想(如用全功能的 VCS 來管理版本),但因為理想而被迫犧牲其他東西時,我會重新權衡。

        如您所說,原文當然是有(某種程度上的)存在價值的,不過要將她保留,也需要付出代價。我只是覺得這代價太高,大部份時候我不願意付。而這個代價倒不是指硬碟容量,而是指我的注意力與集中力,我不想被(我認為是)重點以外的東西干擾到。當然我知道這麼做一定會因此不小心捨棄了或漏失了什麼,不過就算我完整保留了原始資料--比方說在筆記簿中紀錄了整本論語--那些資料也不會成為我的,因為我處理不來。那些資料放在筆記之中,只是屬於……筆記它自己的。而不是我的。

        總之,我的筆記原則是擇優收集,而不是有多少記多少。當然,或許您覺得無論如何咬緊牙關也要將其保留也說不定?沒問題的,不用管我。



        「也難以確定我沒有誤解誤讀(所以需要原始資料)」

        說得對!如果我的目的就是要「考據原意」,那則要記錄原文就是必要的,但另一方面,我通常沒有這種需求(或許您有?)。我往往是在整理自己的知識與思想,而不是別人的「原意」←其實這概念於前面也說過了。

        此外這還有一個問題:如果我們誤解了某物的原意,通常在第一次進行筆記時就已經寫入了誤解的訊息。就算保留所謂的「早期原始筆記」,誤解依然是存在的,只是在未經整理之下更難被覺察而已。



        全能的工具難免笨重難操作,無所不錄的檔案倉庫也一樣嘛。我會用匯出來剔除「相對無用」的舊筆記,也會用 Section 與版本系統,一邊儘量保留舊資料或附屬資料,同時狠狠地將其拋出視線範圍,以最小化注意力成本,這都是為了緩解注意力被過度消耗的方案。

        我覺得您的分流方案也相當合理,都是為了相同目的而採用的策略。

        刪除
      39. 1. 我們立場真的完全顛倒了,之前堅持要保存歷史的不是您嗎XDD

        拿點具體的例子好了,假設您對芝諾悖論很感興趣,有天數學老師講積分時突然扯到芝諾悖論,由於是數學課,您當然是正在記錄數學筆記,但由於您對芝諾悖論也素有興趣,所以想把老師談到關於芝諾悖論的東西記下來。您會怎麼做呢?

        (1) 把它丟在數學筆記裡?(但那和數學關係不是很大)
        (2) 把它丟到芝諾悖論的筆記裡?(但數學老師的說法並非研究芝諾悖論的正統方式,好像也不適合寫在一起)
        (3) 其他...?

        其他細節就不多談了,總之我也清楚為了某些未來潛在價值而犠牲更重要的事並不 smart,我一點也不希望如此;但要把已經記錄的東西丟棄我仍覺得很可惜(更重要的,丟了以後就找不回來了),所以才希望有個兩全其美的方案。


        2. 我認為您對 tag 的分析非常中肯。Evernote 其實有還不錯的 tag 系統,只是如您所述,tag 極容易漏標,雖然它有搜尋難以取代之長處(比如某筆記與某 tag 相關,但其內文不見得有相應的關鍵字),但往往也有不用 tag 的應對方案,最簡單的做法之一是把關鍵字寫進標題或內文。

        比如說有人用 tag 做 GTD,一則筆記若是待處理就標個 !todo、已完成就標個 !done、還要等時機就標個 !pending;但實際上直接把標題寫成 [待處理] XXX、 [已完成] XXX、[等待中][等OOO回信] XXX 可能更清楚明瞭,而且不必透過 tag 介面,見到筆記就知道它是幹嘛的。

        不過我還是有用 tag,主要是有些筆記加標題會變得太冗長,且 tag 系統可以一次操作多則筆記,標題要一則則加,麻煩死了。


        3. 我看您部落格滿常用腳註的,不知您筆記是否有腳註的需求?目前看來 Lonote 似乎沒內建這玩意兒,如果需要腳註,您通常會怎麼處理呢?


        刪除
      40. 1. 不不,其實我的立場沒有變。不過我確實沒有詳細說明,您誤會是理所當然的。這裡重新和您確認一次:我企圖保存,覺得很重要的歷史,僅僅只限於「我想要(我覺得之後可能會用到)」的歷史。

        所以「在可預期的未來沒有任何使用機會」的資料,我就會把他刪除(或保險起見:匯出封存),讓他遠離我的注意力範圍。至於「可能在未來某些特定情況下作為參考」、「不重要但是顯然有價值的參考資料」則是作為歷史記錄與 Section 分別隔離到主檔案庫的其他地方,這同樣是為了與用戶注意力進行隔離的行動。



        我已經放棄腳註系統了。

        我研究的結果是,在 Html 中,腳註功能並沒有優雅合理的實作方式。而且就實用層面上來說,他也並非是必要而無法取代的東西。

        您目前在我文章中看到的 [1] 這類腳註,大都是我早期用 google docs 或 reStructuredText 寫文章時留下來的。如今我學習著儘量不依賴腳註寫作,而用超連結或括號取代;真要寫落落長的腳註時,就手動標一下(註一)這樣。

        雖然確實少了些什麼,不過問題倒也不大。

        刪除
      41. 我的困擾點就在這裡:

        您談的放到歷史記錄或 section,只適用於「筆記的某部分內容」。

        而正如我前面想談的,假如這些內容是「一整則筆記」呢?

        對於我之前的問題,您一慣回應都是您認為那些情況不值得保留,我不打算再爭論價值的差異,畢竟我在意的情境不見得是您在意,這裡就談當您認定一則筆記是「可能在未來某些特定情況下作為參考」、「不重要但是顯然有價值的參考資料」,您會怎麼做?

        依您的說法,這則筆記並不適合刪掉或封存,因為它「有參考價值」;但同時它也沒辦法丟到歷史頁面或 section,或說這樣做也沒用,因為佔用注意力的不是部分內容,而是整則筆記項目的存在──只要它存在,就無可避免會在目錄樹中佔個位置、在搜尋結果出現。

        您會怎麼處理呢?除了刪除和讓它耗用注意力,還有其他選擇嗎?

        刪除
      42. 嗯,還有一種頗為類似的情況,一起談好了:

        想像您長期整理了三則筆記 A、B、C,有天您認為這三則筆記範圍太小了,應該把它們整併成一則 D 筆記會比較清楚,然而當您要整理時發現 A、B、C 各自都有好幾個 section 或歷史版本(或者也許未來是有 section 且各 section 都有一些歷史版本),您會怎麼做呢?

        把 A、B、C 幾則筆記都刪掉嗎?但就算它們的目前版本不重要,長期記錄、留存的 section 和歷史版本也很難說不重要(否則當初就不會留下來了,不是嗎?)

        把它們整併至 D 筆記的 section 中嗎?但如此多的頁面和 section (甚至每則 section 還有歷史記錄)要移動想來就覺「厚工」,也很難避免出錯。

        更糟的是,事後可能會發現把 A B C 併成 D 是錯誤的選擇,嗯....到時把 D 重新拆回 A B C 又是一陣腥風血雨 orz

        諸如此類,這種多則筆記重新整併的情況,您會怎麼處理呢?

        刪除
      43. 「可能在未來某些特定情況下作為參考」--這種狀況下資料只要封存就好。當「特定狀況發生」時再拿出來參考。(1) 版本記錄與 (2) 匯出後刪除其實都在解決這個問題,只是一個自動一個手動而已。更進一步地說,封存只是一個通用的說法,實際運用時甚至可以 (3) 組織一個小資料夾,平常不去打開那個資料夾,這意思與封存也差不多了。

        當然不同的方法有不同的優缺點,對不同的狀況選擇適合的方法即可。以我的例子來說,「夢境記錄」就是一種只有我想翻查靈感時才會用到的資料,而這些資料我以 (3) 的方式集中儲放,方便我想查就能快速查到,但另一方面,他有時也會干擾到我的搜尋結果,是有缺點的。「MS Office XP 使用經驗談」則因為使用機會更低,為了避免前述缺點,被我直接匯出刪除了。

        總之,手段有很多種,可以合併運用。刪除與封存也是可以並行不悖的。



        「不重要但是顯然有價值的參考資料」--Section 就是為此而設計的。「與主要內容有關」的工作清單、自問自答、想法碎片、參考書目一覽都可以放在這裡。



        不過哪些內容要隔離出來,最終還是該由各人的習慣來決定。在下也不是每次都有把上述那些東西給單獨拆開……



        「關於一開始頁面切分不準,日後多個筆記頁整合或切分時,舊版本怎麼辦?」--我建議直接把舊版頁面給匯出封存。也就是把他們給丟出現有倉庫。

        手工進行這種整合與切分一向很麻煩,如果我真的費力去幹這個苦工,意味著我對筆記的切分方法已經到了忍無可忍的地步,這時我會儘快甩脫那些絆住我幹正事的東西,也就是匯出封存多餘資料。讓倉庫在我辛苦整理後,能真正變得像我想要的那樣清清楚楚,而不是一堆包袱。

        我知道您很想保有所有舊版資料,讓您可以從新版檔案中追溯舊版檔案(甚至是「多個」合併前的舊版檔案的歷史),但是這種事情可能沒有通用的解決方案。畢竟維基百科做不到、正規的 VCS 也沒能做到(指追蹤:「許多個檔案,原來是由一個檔案分開而成」,而「某個檔案可能是由多個檔案合併而來」……藉此追蹤檔案分分合合的歷史路徑)。然而我要說的並不是這種實作很難。畢竟再怎麼困難的問題,有需求總能產生動力,我懷疑大家都做不到的原因,是因為這麼做其實沒有什麼好處。另外就私人角度來看,我也想不到實作它能幫我解決什麼重要的問題。

        私以為重新分割檔案的機會不高,重新分割有著大量歷史訊息的檔案機會更低;重新分割後,不滿分割結果,想要基於「重分割前舊版檔案」進行查找與編輯的機會,更是低上加低。「作為整理前的資料與資料的歷史」,將其匯出儲放就已經足夠了--雖然在舊資料重用上有所不便,不過他畢竟是能妥善地將資料給保存下來的。

        以上是基於重用機率不高而採行的策略。如果您覺得「頁面重新切分前的資料」重用機率會很高,也許您應該實作「能夠追蹤檔案切分合併歷史」的版本系統。在下樂見其成。世界上多些選擇總是好的。

        刪除
      44. markdown有腳註的功能
        建議也關注一下markdown
        對寫作者而言簡易實用 而且"文章絕對易讀"
        從我幾年前發現markdown到現在
        相關應用現在已經如雨後春筍一直冒出來

        刪除
    43. 請問 關於 LoNote
      我是找這東西找到這來的
      因為我之前是用ZIM WIKI

      想請問 LoNote 是否有類似 ZIM WIKI 的這幾點特性 或是否有可能實做出來
      1.使用純文字檔案和附件資料夾紀錄
      2.使用WIKI與MarkDown標準
      3.ZIM 表格外掛的功能 -輸入表格方便 又能用任何純文字編輯器修改
      4.ZIM 附件瀏覽器外掛的功能 - 在每頁下方直接顯示 且也沒限制圖或附件內容一定要出現在文件內 對於我常常只在文內放一代表圖,其他多圖直接放在裡面的資料夾很方便
      5.ZIM 目錄外掛的功能 - 在頁面右上顯示文章目錄階層 對常文非常方便
      6.如ZIM 在資料夾內如自己加入文字檔 會自動更新到文章列表
      7.直接用文字檔加入樣本文件夾可自訂新頁面範本 - 對寫人物設定或重複性規格內容的東西很方便
      8.自動完成功能(輸入到 現有文章標題的開頭字 會自動在輸入時出現可選擇清單 然後點用後也自動變成文字連結)
      9.匯出 匯出時可以將一整個特定樹下的文章內容都串在一起 變成一整篇單檔文章 (寫小說很方便)

      ZIM本來沒有的
      10.支援複製文章時,圖檔會自動變成附件,而不是直接連結(我覺得這很糟糕,因為網路文章一久,網上的圖實在非常容易不見,最後文章內只剩X燒包....)
      11 複製文章時 不會只有純文字 至少有MarkDown包含的格式和圖片
      12 建立新文章和複製成新文章時 可選要用純文字 WIKI MARK HTML 或自訂的樣板
      13.MarkDown 編輯/顯示 雙欄顯示
      14.時間軸故事點子卡片功能 (這點我是不奢求...畢竟太少有可能會有這功能的=_=...)
      15. 這大概真的有點奢求.. 支援某樹下文章可以直接發佈到WordPreess和blogspot 這我試過的例如EVERNOTE+WORDPRESS外掛都不好用

      我本來是ZIM同時在WIN和UNUMTU用的
      但WIN版的ZIM停留在0.63 而且作者已經不想發佈win0.65...
      (0.63在win下中文之原有問題 連建立文章名稱用中文都會衝碼無法建立)

      我覺得ZIM如您另文所言,有許多地方非常獨到
      所以想找一個能替代的,著實很傷腦筋中...

      回覆刪除
      回覆
      1. 建議暫時別用 Lonote,我最近正在發展測試 Lonote 的後繼專案,已經在我自己的機器上試行了一個月左右。因為我自己也受不了 Lonote 的某些地方了(嘛阿宅要滿足是很難的)。因為架構差異非常大,所以如果您現在用了 Lonote,之後轉到新格式時會丟失部份小細節如時間戳或 html tag。而且也可能和您現有的使用目標不合。

        過一陣子後我覺得差不多時會再 po 一篇講後繼專案的部落格文。如果您想要搶先看看的話請看這裡:
        https://bitbucket.org/civalin/lolinote

        刪除

    ☆每日吐嘈,有益身心☆
    …不過還是請手下留情別太狠啊。