treemacs文件列表刷新速度缓慢?

比方说:

你当前正打开着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-modet,并不会卡死。

我的系统是windows7。