Subject: bug#35418: [PATCH] Don't poll auto-revert files that use notification

From: Eli Zaretskii <[email-masked]>
Date: Thu, 25 Apr 2019 13:04:57 +0300

> From: Mattias Engdegård <[email-masked]>
> Date: Thu, 25 Apr 2019 11:56:59 +0200
> Cc: [email-masked], [email-masked]
> 
> >  ;; If we have file notifications, we want to update the auto-revert buffers
> >  ;; immediately when a notification occurs. Since file updates can happen very
> >  ;; often, we want to skip some revert operations so that we don't spend all our
> >  ;; time reverting the buffer.
> >  ;;
> >  ;; We do this by reverting immediately in response to the first in a flurry of
> >  ;; notifications. We suppress subsequent notifications until the next time
> >  ;; `auto-revert-buffers' is called (this happens on a timer with a period set by
> >  ;; `auto-revert-interval').
> 
> Thank you, interesting! In any case, that should not be a problem: the patch takes care of it in a more principled way, by the means of a timer. Currently, auto-revert is inhibited until next periodic poll, which can be anything between 0 and 5 seconds away. The patch sets this to a fixed value (2.5 s).
> 
> > If you look at bug reports and discussions around the time this
> > comment was written, you will find the descriptions of the use cases
> > that caused this design.  AFAIR, the main problem was with inotify,
> > not with w32notify.
> 
> The inotify problems at the time seem to have stemmed from not using unique notification descriptors. This was fixed some time ago (158bb8555d etc, bug#26126).

I'll let Michael decide on this.

>    "^" (regexp-opt '("/afs/" "/media/" "/mnt" "/net/" "/tmp_mnt/"))
> 
> If that regexp is acceptable as rough heuristics on Unix, surely something like the regexp proposed, matching \\SOMETHING\, shouldn't be out of the question on Windows? Full precision cannot be attained, as you point out, but perhaps we can make life easier for the user.

on Windows, SOMETHING is just the name of the machine which exports
the drive, it can be anything.

> Are you arguing that the default value of auto-revert-notify-exclude-dir-regexp should not be extended in the proposed way, or that the variable is fundamentally incompatible with the patch?

I'm questioning the usefulness of extending the default value, yes.
But I don't have strong views on that.

Thanks.