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

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Thu, 25 Apr 2019 11:56:59 +0200
> Cc: 35418@debbugs.gnu.org, michael.albinus@gmx.de
> 
> >  ;; 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.