From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#35418: [PATCH] Don't poll auto-revert files that use notification Date: Thu, 25 Apr 2019 13:04:57 +0300 Message-ID: <83o94uz9h2.fsf@gnu.org> References: <83sgu71b91.fsf@gnu.org> <74CB5185-5DA1-4786-BD9C-9EEB3D43B3C1@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="108057"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35418@debbugs.gnu.org, michael.albinus@gmx.de To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 25 12:21:24 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJbVL-000RxO-BY for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Apr 2019 12:21:23 +0200 Original-Received: from localhost ([127.0.0.1]:54847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJbVK-0002hN-8U for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Apr 2019 06:21:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJbUz-0002Dj-Rr for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:21:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJbGU-0000Nu-KZ for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:06:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43989) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJbGU-0000No-HG for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hJbGU-0004Vd-BN for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 06:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Apr 2019 10:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35418 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35418-submit@debbugs.gnu.org id=B35418.155618673317292 (code B ref 35418); Thu, 25 Apr 2019 10:06:02 +0000 Original-Received: (at 35418) by debbugs.gnu.org; 25 Apr 2019 10:05:33 +0000 Original-Received: from localhost ([127.0.0.1]:57531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJbG0-0004Uq-Pz for submit@debbugs.gnu.org; Thu, 25 Apr 2019 06:05:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJbFy-0004Ue-Ak for 35418@debbugs.gnu.org; Thu, 25 Apr 2019 06:05:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJbFq-0008KG-O5; Thu, 25 Apr 2019 06:05:23 -0400 Original-Received: from [176.228.60.248] (port=3699 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hJbFm-0006vm-Id; Thu, 25 Apr 2019 06:05:20 -0400 In-reply-to: <74CB5185-5DA1-4786-BD9C-9EEB3D43B3C1@acm.org> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Thu, 25 Apr 2019 11:56:59 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158241 Archived-At: > From: Mattias Engdegård > 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.