当在编辑器中打开文件(比如Sublime或Atom),并且在编辑器外编辑文件时,编辑器总是拒绝刷新它显示的文件。这种情况很少发生,因为很可能只会使用单个工具在特定时间范围内编辑文件。当文件是只读时,这显然不是问题。例如,在读取系统错误日志时,文件将在系统运行时更新,并且可能有新的错误日志,但日志文件不会被编辑,因此不会导致冲突。
但是,当文件由git pull
更新时会导致问题。
当一个人提取回购的最新更新时,他可能会在编辑器中打开一个文件,在更新中进行了一些更改。如果编辑器无法刷新文件,则文件将与旧内容一起保存,并且任何新更改都将丢失。
有时候,使用sourcetree反转hunk是很烦人的,但是当有许多文件被更新时,这个覆盖可能会被推到git服务器中而不被注意 - 直到发生错误。目前我们使用git log --follow -p -- file
命令来定位并恢复错误,但如果没有及时发现覆盖,则无法手动复制行。有没有办法首先防止这种覆盖?
答案 0 :(得分:4)
中讨论的内容当编辑器(主要是我们团队中的Sublime或Atom)打开文件夹,并且编辑器在编辑器外编辑时,编辑器中的内容有时会刷新,但有时则不会。
像file-watcher这样的Atom软件包可以通过在检测到编辑器外部的修改时提示重新加载每个文件来帮助缓解此问题。
对于SublimeText,您有同样的问题reported in this thread。 如that thread中所述,当通过网络共享访问文件时,该问题在Windows上更为相关 File Reloader可以提供帮助,但不会检测到外部变化。
SublimeText thread提及设置(2016)
{ "always_prompt_for_file_reload": true }
但是当编辑器和保存的文件中都有更改时,这可能无济于事:editor like Visual Studio Code通过以下方式解决了这个问题:
如果您尝试使用VSCode保存文件时双方(从磁盘和编辑器)都有更改,编辑器将警告您这种情况,文件比较将允许您决定要执行的操作。
这就是为什么使用SublimeText(除"always_prompt_for_file_reload"
设置之外),您可能需要FileDiff plugin。
它允许使用Saved:
答案 1 :(得分:1)
有没有办法在第一时间阻止这种覆盖?
是的,因为您的编辑无法通过文件系统的中断进行检测,然后通过每3秒定期轮询一次文件系统来执行它们。
在Notepad ++上编程时,这种失败非常明显,这就是为什么定期检查文件系统中文件更改的轮询插件是非常必要的。
对于Sublime Text
和Notepad++
,插件为:
由于在多个文本编辑器/ IDE上使用相同文件的程序,我使用了很长时间。然后当在编辑器之间交替时,我大部分时间都放松了我的工作,因为他们没有从文件系统重新加载文件。但是,在安装了上述插件之后,我再也没遇到过这个问题,或者因周期性重新加载而发现性能问题。