reload-all should work if one of the files fail to reload

[sigmaSd]

reproduce steps:

• touch a b c
• hx
• :o a
• :o b
• :o c
• rm a
• :reload-all

reload-all now doesn't reload anything because it fails because a is not found anymore

I think this behavior is annoying in practice, I know the file doesn't exists and I just want to reload the other ones, and currently it seems the only workaround to fix this is to either reload the files manually one by one or by restarting helix

[kirawi]

Duplicate of https://github.com/helix-editor/helix/issues/5665 and will be resolved by https://github.com/helix-editor/helix/pull/7948

[kmicklas]

This is not a duplicate of #5665; that describes a different problem.

I tested #7948 and it does not fix the issue described here. A file having modifications inside Helix is a different state than it being removed on disk externally.

I believe this issue should be reopened and this specific issue should be fixed in its own PR.

[webdev23]

That's an important behavior to force reload-all to actually reload it all every time. Right now, using many buffers, it's misleading and can result to loss of data and confusion. Helix should implement a File watcher able to reload automagically modified files, that will solve this issue, and many others in many developers flow.

[kirawi]

A file watcher is non-trivial: https://github.com/helix-editor/helix/issues/1125

[webdev23]

It may be non-trivial or whatever, but that is a major inconvenience.

For the record, similar TTY text editor all have such auto-reload capabilities at external file change, as an option, for most it's enabled by default, and for all it doesn't come as a plugin, it's built-in.

It was implemented very early in those projects, because it's what's make them trust-able to edit files!

Focus editor: https://github.com/focus-editor/focus/releases/tag/0.1.5 Micro editor: https://github.com/zyedidia/micro/blob/master/runtime/help/options.md Neovim, enabled by default, can be deactivated with: :set noautoread Emacs: global-auto-revert-mode https://www.gnu.org/software/emacs/manual/html_node/emacs/Auto-Revert.html JED editor: https://www.jedsoft.org/jed/doc/jedfuns-9.html#ss9.9 MCedit: 'fast dir reload'. http://www.trembath.co.za/mctutorial.html (...)

Just as well, the most basic graphical editor, from Xed to Geany, to all kinds of IDE, are doing auto-reload or warn users, out of the box.

I understand the technical aspects of using system level notifiers, or polling on disk in loop. But a simple md5 of a directory won't eat the planet, it should not be hard at all to implement. Not enabling auto-reload is an opinion, not a feature. If Helix wants to become post-modern, without plugins, well ok, but this can only work opinion less.

[kirawi]

Please post that comment over in the linked issue instead since it's for file watching.

We want to implement it, and @pascalkuthe has been working on it. From my understanding of what he's seeking to address, it's not as straightforward as you think it is. I believe he mentioned that these polling libraries may sometimes miss events and accidentally cause you to overwrite files that have been modified by an external process. But perhaps he can clarify if I am wrong.

Ref: https://matrix.to/#/!zMuVRxoqjyxyjSEBXc:matrix.org/$TzrzYSqDO95_AzgEvSA1UaAIN2Bjg5K_4S1FBMpmd1I?via=matrix.org&via=mozilla.org&via=envs.net

It is very similar the difference is subtle. Whenever you spawn a watcher (no matter which one inotify or poll based) noitfy calls std::thread::spawn and then does all processing inside this new thread (for the poll based watcher it does more or less the same thing as my code but using std::thread::sleep isntead of tokio sleep). By comparison and async function yields to tokio which manages a fixed number of threads (equal to to the number of CPU cores by default) and schedules these tasks on these threads.

As long as the timeout is not reached tokio does not schedule tasks so they do not cause problems. Tokio is fundamentally designed for high throughput with a large number of waiting tasks so it's very efficient to just spawn loads of them.

System threads are not optimized that way and just spawn 100 threads is going to cause a ton of overhead. Each thread has roughly the same priority so if we spawn 100 notify watchers they get more priority they take significant processing time away from tokio/the rest of the editor. Therefore notify offers an API to easily watch many different files with the same watcher (thread) however you then need a seperate tokio tasks that recives all files changed events and forwards them. That means you need to build some kind of registry to track which channel is interested in which is not trivial to do efficently.

By comparison the above function can be just spawned 100 times and tokio will ensure it's scheduled well. Scheduling overhead for tokio is basically non existend even for huge number of tasks.

https://matrix.to/#/!zMuVRxoqjyxyjSEBXc:matrix.org/$8D80mdHn1VTmpUYWmRXEAMOWpq7U3q0nKZCdxDsZHdw?via=matrix.org&via=mozilla.org&via=envs.net

[MacOS] implementation is pretty good (because the [FS] abstraction is). But the [inotify] implementation goes exactly against all best practices for recursive file watching which can lead to dropped events and many other oddities. If we are going to use a file watcher it needs to be something reliable.

Watchmen gets that right but it's an external binary which I am not comfortable depending on.

It also spawns its own mix instance and does not integrate with tokio/async which I don't love either