之前改了一個 everwatch.rb
可以在背景偵測 Evernote 內文的改變,讓 Marked 2 來做 markdown preview,但最近也不知道是不是更新了 Marked 2 (2.5.0),功能執行起來似乎有點異常:
原本運作的方式是用一個 infinite loop 一直 watch Evernote 有無更動,大約每兩秒把資料從 html 的格式轉成純 txt 格式寫進去,但 Marked 2 會出現一直重覆 loading 數次的現象,再加上 Marked 2 會一直從頭 scroll 到修改的地方,還蠻煩的,但原因也不太清楚是什麼。
後來覺得似乎也不需要這麼頻繁的 update 這個 preview 視窗,在內文區寫作的時候,其實也不會一直去看 preview 的結果,既然要修 bug,便改用 Mac 內建 Service 的方式,在需要 preview 的時候再用快速鍵來 trigger,設定方式如下:
1. 用 Automator 新增一個 Service
2. 拖入一個「執行 AppleScript」
3. 設定作用的程式和貼入程式碼,儲存 Service
4. 指定快速鍵
在『系統偏好設定 > 鍵盤 > 快速鍵 > 服務』中指定,因為先前有指定在 Evernote 中才有作用,不會影響到其他的程式。如此一來,當想要看看 Markdown render 出來的結果時,在 Evernote 中按下 Ctrl + Z 即可。
神祕現象
原本的 everwatch 是個 ruby script, 不過裡面還串了 AppleScript 和 shell script,所以這次改版也想簡化一下,縮成只有 AppleScript 和 shell script(好像也沒多簡嘛!不過很多功能要純用 AppleScript 來做真的很耗時間又冗長啊!)。
在 try 的過程中也發現了個神祕的現象:
- Marked 2 在檔案「一被修改」的時候就會馬上重新 render
- 用 pipeline redirect output 到檔案 (
>
操作),似乎會先把檔案清空,再寫入資料
由上面兩點來看,如果直接把 pipeline 輸出到最終的檔案,Marked 2 render 出來的就會是個空檔案,因此只好先用一個暫存檔把處理過的文字存起來,再 mv
過去要顯示的檔案。而之前的 ruby 版本是用 ruby 自己的 file operation,所以在背後可能避免了這個問題。另一個可能的解法是用 AppleScript 來實作 file I/O,但會有一些小問題,而且也會讓 script 變得有點複雜,就不考慮這條路。
另外一個神祕現象是,記事的內容和用 AppleScipt 取得的 selection 似乎會有一小段的時間差,大約是 1–2 秒左右吧!所以如果一打完字就想馬上 update preview 視窗的話,會看到前幾秒的狀態,這可能跟整個 AppleScript 的底層機制有關,暫時沒什麼好方法。
之前的 ruby script 會需要考慮 Evernote 儲存資料的路徑,而且不同版本的 Evernote 還有不同的 path,就我目前遇到的,至少有下列兩種(而且非免費版的帳號似乎又不同了):
~/Library/Containers/com.evernote.Evernote/Data/Library/Application Support/com.evernote.Evernote/accounts/www.evernote.com/#{account}/content
~/Library/Application Support/com.evernote.Evernote/accounts/www .evernote.com/#{account}/content
用 service 來 trigger 就不需要 care 這個路徑,code 可以相對簡潔一點。
改用 Service 來 preview 主要是為了解決 Marked 2 的奇異行為,額外獲得的好處是,只會在需要的時候才做 file I/O,或許在心理上,會覺得比較不那麼傷 SSD 硬碟吧!XD