比方说：
你当前正打开着treemacs的文件列表窗口，此时创建一个新文件 或 重命名一个文件，treemacs的文件列表刷新速度缓慢，大约要3-5秒才能刷新。
请问这是因为treemacs内部有一个timer不断的在扫描我的文件夹吗？
这样如果长期挂着treemacs会不会把硬盘扫坏了？（不确定磁盘驱动是否会做保护）
为什么做不到和VSCode那样即时更新呢？
linux没这个问题，就是即时刷。如果有这样的问题可以说是很严重了，社区是不会买帐的。
mac 上也没有问题。是不是项目太大，magit 导致的问题？
我是在windows上缓慢，linux和mac上没试
不过好像有个 treemacs-filewatch-mode 我试一下。。。
设置
(setq treemacs-filewatch-mode t);
(setq treemacs-file-event-delay 1000)
后问题解决。
你们都设置吗？还是保持默认？默认需要5秒。。。
filewatch-mode开了之后从treemacs里进行文件操作就会立刻刷新了，event-delay好像是你从外部进行文件操作时一个固定的刷新时间。楼主没按github的配置来吧，上面是开了filewatch-mode的，不过另外一个就是5秒。这个包作者有点奇怪，这样的配置本来里应该默认开的，却是要一大堆写到配置文件里才开。
原来你是没有开 treemacs-filewatch-mode 啊
开了。。
但我是照着作者的github配置的，今天才发现他设的treemacs-file-event-delay是5秒。。。
（另：如果你不使用Github的设置，默认也是5秒）
不知作者是出于什么样的目的，让大家都去设5秒？（或许真有磁盘问题？）
SSD 读取文件没有多大问题的
然而实际上文件更改信号是文件系统发给Emacs的，并不是Emacs去论询，有锅也不该Emacs背。
看fontnotify.el的注释也提到
;; This package is an abstraction layer from the different low-level
;; file notification packages `inotify', `kqueue', `gfilenotify' and
;; `w32notify'.
设那么大延迟是因为作者觉得短时间多次刷新Treemacs不太好，尤其是配合一些自动保存工具的时候。
你设变量的时候也顺手看看Docstring吧。没有根据的猜疑是没有建设性的
1 个赞
感觉他设的也有点太大了。。。
如果是2秒，估计也就不会care。。。
我现在发现我如果treemacs filewatch mode设置为t，那么保存就会卡死。我windows10会这样，linux则不会。不知道你有遇到过么？
我的treemacs-filewatch-mode是t，并不会卡死。
我的系统是windows7。