为了只保存我输入的字节，我们将文件作为唯一事实来源

明明只修改了 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 会把我交给它的文件原样还给我。