我的org文件昨天还是850K，今天又往里面添加新的内容了，但是minor mode显示的体积却变成750K了，Org文档会自动进行体积压缩吗？如果真的压缩了，这延迟也是够大的。
问题出在Spacemacs minor mode里的文件体积显示上，有人清楚它是如何计算文档体积的吗？
怕丢失还不用版本控制？
你应该用外部的程序，比如du命令查看文件体积。而不是问网友来获取心里安慰。
org不会自动压缩文件。
Don’t judge, just answer.
只想要回答，那就不要说什么自己没用版本控制，又说自己很担心数据这些问题无关的话
I don’t need you to teach me the manners.
所以你确定你知道org不会进行体积压缩，那么minor mode出的体积计算又怎么解释？
org文件就是plain text，plain text的所有细节都是可见的。除非你显式用gz这些执行压缩，否则org悄悄做什么你会不知道么？
你也没说你用了什么minor mode来显示文件体积，是builtin的还是社区的？会不会有bug？会不会计算方式有问题？
所以你为什么不用du，文件管理器等来确定你的org文件的体积？
嗯，我已经发现了，du和文件管理器的体积记录没问题，是minor mode里的计算出问题了，用的Spacemacs，惯常看底下的体积大小，不清楚这里怎么计算的。
有可能是行尾的空格引起的
如果minor mode计算体积时不考虑空格，那么在我未删除空格，并且添加了字符串的情况下，体积显示也不应该缩小的。
minor mode计算文档体积不考虑空格可以给minor mode显示的体积小于du显示的体积提供一个解释。
minor mode里显示的数字是characters count，可以通过M-x count-words 得到lines， words，characters的总数，所以这里显示的是总的characters数目，并非文件体积。可以参看这里。
字符数和文件大小不一定相同，比如 UTF-8 里一个中文字符相当于三个英文字符。或许跟这个有关。
(length "中")
;; => 1
(string-bytes "中")
;; => 3
1 个赞