Re: A project-files implementation for Git projects

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

>> It is signalled by our inotify backend as `q-overflow' event, but
>> filenotify.el doesn't care. And I haven't checked the other
>> backends. Maybe we shall expose it in filenotify.el (independent where
>> this discussion ends)?
>
> Expose it and do what?  About the only thing you can do is switch to
> the alternative implementation (like turn off auto-revert-use-notify),
> but (a) not every feature even has such an alternative, and (b) you
> will still miss events, because there's no way to recover the lost
> events.

In filenotify.el, we use already an internal `stopped' event, see (info
"(elisp) File Notifications")

It is raised when somebody calls `file-notify-rm-watch', or a watched
file is deleted or renamed. Since it is documented, packages using
filenotify could care about. And yes, autorevert falls back to polling.

If `q-overflow' arrives in filenotify, we could send a `stopped' event
for all valid watch descriptors which belong to inotify. I don't say
that every package can be profit from this, but it is better than doing
nothing.

Btw, I haven't seen ever `q-overflow'. So I wouldn't know at the
beginning, how to write a test in filenotify-tests.

Best regards, Michael.