From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- ' Date: Tue, 24 May 2022 19:52:37 +0200 Message-ID: <87bkvmom1m.fsf@gmx.de> References: <87r14lfpui.fsf@miha-pc> <87mtf7nnok.fsf@gmx.de> <87leuqgbwz.fsf@miha-pc> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1106"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 55578@debbugs.gnu.org To: Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 24 19:53:17 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntYib-000Abi-2v for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 May 2022 19:53:17 +0200 Original-Received: from localhost ([::1]:33638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntYiZ-0007Zf-Jx for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 May 2022 13:53:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntYiM-0007ZF-PP for bug-gnu-emacs@gnu.org; Tue, 24 May 2022 13:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59389) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ntYiM-0002ly-84 for bug-gnu-emacs@gnu.org; Tue, 24 May 2022 13:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ntYiM-0002w9-4u for bug-gnu-emacs@gnu.org; Tue, 24 May 2022 13:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 May 2022 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55578 X-GNU-PR-Package: emacs Original-Received: via spool by 55578-submit@debbugs.gnu.org id=B55578.165341476911267 (code B ref 55578); Tue, 24 May 2022 17:53:02 +0000 Original-Received: (at 55578) by debbugs.gnu.org; 24 May 2022 17:52:49 +0000 Original-Received: from localhost ([127.0.0.1]:53286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntYi9-0002vf-FR for submit@debbugs.gnu.org; Tue, 24 May 2022 13:52:49 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:38647) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ntYi6-0002vR-Px for 55578@debbugs.gnu.org; Tue, 24 May 2022 13:52:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1653414759; bh=qjL/pYzMhjm/Jo3wPGa/rzgF6+3MQUWKyN7u6X81ybo=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=QbVCvXIpGS+wrBSV+rZ6FVbYH0nFvAYEUl93OMN4YI4xOEYyLdIWuduHj+YqzVcL2 Q4c49r8YzIdG9bjjGbqZKJQFMpbOFkfAFsBxdqM08pw2lYkPv4hgcHuLDq3E6fAenh R5CDhZXvYosP8nV0UXK2OrZKdDyBierqZUDf9O+E= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([213.220.149.14]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MWzfv-1oLxSI2uF7-00XIe2; Tue, 24 May 2022 19:52:39 +0200 In-Reply-To: <87leuqgbwz.fsf@miha-pc> (miha@kamnitnik.top's message of "Tue, 24 May 2022 17:58:36 +0200") X-Provags-ID: V03:K1:C/+McGujBHM1fByraeDgNVFo5SY6Gg7ix92wyjelqJcDAkS/ttC tXE2WLfd5wvH7IJM/3gaTb5JsZxehGQqq01pZmZm8BME6Q9XaiVMNcvIng9YpLJq0keWRUM dM2iuBlBzEQ6mrCQ516UX0CZcmWdrMrlXU7amxEE+ldebcPSIDrD/LDZMpZsvY4NXcT+CAb UPYMT7xlyOfhcsh4/R+ng== X-UI-Out-Filterresults: notjunk:1;V03:K0:Amre5xq5C1g=:a2lCmtcOmbjuqAGhgrXDMj QhWjsWGz7hZV6YBobbxNvJRBOM1zVocWnCiqPeoi2dYoUjZGi6jl4gbo3ldwccAXqAupKO657 R5I4ZUjkxrrfSNRsqpeyTlqIYLMZ5CvbOkui3vHQJq76TB1k259iw6zVPDl223zZ/TGbIXa/J zhSZgfAkGFGCFl2XWai/p7Q8yWvzG+K/xk5VXoAOsvDqslO8iq2BoUbOJD/zMZ8e0n2hRi5Ct MIh1MuKuaJTBIGn9tZlZznlBNNSxAkv+kwKZj14qU7+XAJU0QuwWPcX+rGPfmPK5zFabs5yzJ 4f7Z4Q0gj5Gc8laLM7kYEG+GgHEIqEyI5oWxiBSYFXw6cs4nqZMq+5x1mWYoHpPxm+Rq7YuxL jEAuAZZxT4EfLoEH598qMYp1svBR8qs5nIvKNlGJJ+OLGNynuVnS4AKapvgCQK8A8LAUTBJM4 Ky8+NN9URpKXAQrRq3Sqzd1X0qHpPz7rUqk3ukzV4d5FO+7+FZaGYWJq8qfHirLCyJVPMtJET AgpnrnRxR52yeCC0D1ZfcOGKzfvcFa8ZAoONr+OrbTu/6Y7uj6y8Et+6n/mbrB4K3VnCE+nKE 179ExxvAsWiwNnZyGFSynShzITYXq4jvVIUnTXJ6wyu9frvNwxe/UFmQdItvWlHOlFcBKPAp1 ApEWFnSZxOCBFfd6nH0eVl1CkRo7RIk7ids0g1tbzAoOUB2xKxCnxNLZBrrCUaDPepgh1uUW8 dh6F1kh1STTJNY42HZTx8BD3FLI5i6KCA4DCaG8O+7flrKXhyXp0MsI2QAHI39lYIsFF6/rG X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233021 Archived-At: writes: Hi, > I imagine that after receiving a 'delete' event, auto-revert-mode could > set up a file-notify watch handler on the directory containing the (now > deleted) file. This handler would respond to a 'create' event > corresponding to the filename by reverting the buffer, removing the > directory file-notify watch and (re-)adding an ordinary file-notify > handler on the file. Anything goes. But there are traps. > Are there any obvious flaws with this approach that I'm missing? See the notifications the auto-revert handler receives: --8<---------------cut here---------------start------------->8--- file-notify-handle-event (file-notify ((1 . 1) (delete) "foo" 0) file-notify--callback-inotify) file-notify-callback (1 . 1) deleted "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" "foo" auto-revert-notify-handler) "/tmp/xxx/foo" "/tmp/xxx" auto-revert-notify-handler ((1 . 1) deleted "/tmp/xxx/foo") file-notify-handle-event (file-notify ((1 . 1) stopped "/tmp/xxx/foo") auto-revert-notify-handler) auto-revert-notify-handler ((1 . 1) stopped "/tmp/xxx/foo") --8<---------------cut here---------------end--------------->8--- The relevant event `auto-revert-notify-handler' reacts on is the `stopped' event. In this case it deletes the file monitor, and continues with polling. The `delete' event, received before, is ignored. Receiving the `stopped' event can have different reasons. It happens when the monitored file is deleted (like in our case). It could also happen when the user has killed the corresponding file monitor, either explicitly (calling `file-notify-rm-{all-watches,watch}'), or implicitly by calling something else. The autorevert package cannot know the reason, and it cannot know, whether the file is deleted and will be recreated, possibly. So we cannot implement an automatism as above. What we could implement is a mechanism, which checks while polling, whether file notifications could be instantiated instead. This does not need to be restricted to the case, that the file was deleted and then created, again. It could be activated for any auto-revert polling activitiy, and it must be an opt-in to be configured by the user. Or at least restricted to use cases where it would make sense, like monitoring a git repository. For example a minor mode `auto-revert-restart-notify-mode'. > Best regards. Best regards, Michael.