以檔案為真相來源，只儲存我實際輸入的位元組

明明只修改了 Markdown 表格裡的一個詞，Git 有時卻會顯示整份文件都被更改了。

這是因為編輯器在儲存時，重新整理了表格的間距和換行。也就是把使用者沒有輸入的空格寫進了檔案。Typora 為了對齊表格欄寬，在分隔線之間填入空格，就是這類例子。

mote 的儲存方式不同。它會保留檔案的原始文字，只在上方呈現粗體、表格、公式等畫面效果。因此儲存時，只有使用者修改過的位元組會有所不同。

儲存前就能確認變更量

mote 會在狀態列顯示儲存時將變更的位元組數。

它會比較第一次開啟檔案時的原始內容與目前內容，只計算實際有所不同的部分。編輯後會顯示 17 B 等待儲存，全部復原後則會變成 與已儲存的檔案相同。儲存後，儲存完成 · 17 B 會一直保留到下一次編輯為止。

這個數字不依賴 Git 也能運作。即使資料夾不是 Git 儲存庫也能看到，而且不受暫存或提交狀態影響。

不過，它與 Git diff 中會顯示的變更量相同。因此在儲存之前，就能確認是否只有自己修改的部分會發生變更。

修改表格的一個儲存格，就只會變更那一格

編輯表格時，最能看出這種差異。

在即時模式（Live）中，表格會顯示成格狀。只有游標所在的儲存格會變回原始文字。修改其中的一個詞並儲存後，狀態列會顯示 +8 −6 B。Git diff 中也只會出現相應的那一列。

欄位對齊方式和分隔線之間的空格會保持原樣。* 項目符號或行尾的兩個空格也不會被更動。原本最後一行沒有換行的檔案，也不會被新增換行。

貼上文字時也一樣。它不會將剪貼簿中的文字轉換成其他格式，而是原樣插入。新增的量可以立即在狀態列確認。如果不滿意，只要復原一次，就能回到與已儲存檔案相同的狀態。

檔案的其他特徵也會保留。CRLF 仍會是 CRLF，即使檔案混用了 LF 和 CRLF，也會原樣儲存。BOM 和最後一行的換行也會遵循原始檔案。每個版本都會透過往返儲存測試來確認這項行為。

檔案變更只會由使用者的操作觸發

mote 會在三種情況下向文件新增位元組。

使用者輸入或貼上文字時、確認剪貼簿中的圖片後將其儲存並插入連結時，以及拖曳圖片邊角調整大小並將該數值記錄在替代文字中時。

這些全都是由使用者直接開始的編輯。變更記錄中也能確認哪些內容發生了變化。

它也不會在文件旁另外建立檔案。像表格欄寬這種無法包含在 Markdown 中的資訊，不會另行儲存，也不提供相關功能。

設定、最近使用的檔案、20 份備份等應用程式資訊，只會儲存在使用者家目錄的狀態資料夾中。因此在 Git、Dropbox 或 Syncthing 中，文件資料夾就像沒有 mote 一樣運作。

相對地，它不會擅自替你修正檔案

忠實保留檔案，也代表它不會任意修正錯誤的語法。

損壞的表格、未關閉的程式碼圍欄，以及錯位的清單縮排，都會依照 CommonMark 的解析結果原樣顯示。如果顯示結果與期望不同，就必須在原始碼模式（Source）中自行修正。

不知道儲存時會改變什麼的編輯器，只是在借用你的檔案。mote 則會把你交給它的檔案原樣還給你。