GNU bug report logs - #55578
29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'

Previous Next

Package: emacs;

Reported by: miha <at> kamnitnik.top

Date: Sun, 22 May 2022 17:09:02 UTC

Severity: normal

Found in version 29.0.50

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55578 in the body.
You can then email your comments to 55578 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#55578; Package emacs. (Sun, 22 May 2022 17:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to miha <at> kamnitnik.top:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 22 May 2022 17:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: miha <at> kamnitnik.top
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'
Date: Sun, 22 May 2022 19:18:29 +0200
[Message part 1 (text/plain, inline)]
Visit a file in a clean git repository, modify it and save its buffer.
Turn on auto-revert-mode in its buffer.

Run 'git checkout -- <filename>' and notice that auto-revert-mode
doesn't revert the buffer immediately using 'notify', it only reverts it
according to auto-revert-interval.

This is in contrast to modifying the file with a command like
'echo test >> <filename>', after which auto-revert-mode reverts the
buffer instantly using 'notify'.

This seems to be because prior to writing the file, 'git checkout'
unlinks it first. It would be nice if auto-revert-mode worked with
notify in such cases as well.

git version 2.36.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.6)
 of 2022-04-20 built on miha-pc
Repository revision: 4714f34928c12cc9ebda7c115526db4aa87c0d51
Repository branch: tmp
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Artix Linux

Configured using:
 'configure --without-libsystemd --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice
simple cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese composite
emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help
abbrev obarray oclosure cl-preloaded button loaddefs faces cus-face
macroexp files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 59212 9167)
 (symbols 48 5734 0)
 (strings 32 16445 1783)
 (string-bytes 1 547865)
 (vectors 16 11787)
 (vector-slots 8 271542 16531)
 (floats 8 21 25)
 (intervals 56 334 7)
 (buffers 992 11))

[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#55578; Package emacs. (Tue, 24 May 2022 12:03:01 GMT) Full text and rfc822 format available.

Message #8 received at 55578 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: 55578 <at> debbugs.gnu.org, miha <at> kamnitnik.top
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Tue, 24 May 2022 14:02:35 +0200
miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

Hi,

> Visit a file in a clean git repository, modify it and save its buffer.
> Turn on auto-revert-mode in its buffer.
>
> Run 'git checkout -- <filename>' and notice that auto-revert-mode
> doesn't revert the buffer immediately using 'notify', it only reverts it
> according to auto-revert-interval.
>
> This is in contrast to modifying the file with a command like
> 'echo test >> <filename>', after which auto-revert-mode reverts the
> buffer instantly using 'notify'.
>
> This seems to be because prior to writing the file, 'git checkout'
> unlinks it first. It would be nice if auto-revert-mode worked with
> notify in such cases as well.

Indeed, git deletes and (re-)creates the file. See the following file
notify events, when monitoring the git repository (/tmp/xxx is the repo,
/tmp/xxx/foo the file). This happens, after calling "git checkout -- foo":

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 0) (delete) "foo" 0) file-notify--callback-inotify)
file-notify-handle-event (file-notify ((1 . 0) (create) "foo" 0) file-notify--callback-inotify)
file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
--8<---------------cut here---------------end--------------->8---

The corresponding events for the file /tmp/xxx/foo are

--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---

As you can see, file notifications are stopped after receiving the
'delete' event. This is a feature of our file notifications implementation.

Running "echo test >> foo" instead shows the events

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
file-notify-callback (1 . 0) changed "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" nil auto-revert-notify-handler) "/tmp/xxx" "/tmp/xxx"
auto-revert-notify-handler ((1 . 0) changed "/tmp/xxx/foo")
--8<---------------cut here---------------end--------------->8---

This works as expected. So I fear there's nothing we can do.

Best regards, Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#55578; Package emacs. (Tue, 24 May 2022 12:09:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#55578; Package emacs. (Tue, 24 May 2022 15:49:01 GMT) Full text and rfc822 format available.

Message #14 received at 55578 <at> debbugs.gnu.org (full text, mbox):

From: <miha <at> kamnitnik.top>
To: Michael Albinus <michael.albinus <at> gmx.de>, 55578 <at> debbugs.gnu.org
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Tue, 24 May 2022 17:58:36 +0200
[Message part 1 (text/plain, inline)]
Michael Albinus <michael.albinus <at> gmx.de> writes:

> Indeed, git deletes and (re-)creates the file. See the following file
> notify events, when monitoring the git repository (/tmp/xxx is the repo,
> /tmp/xxx/foo the file). This happens, after calling "git checkout -- foo":
>
> --8<---------------cut here---------------start------------->8---
> file-notify-handle-event (file-notify ((1 . 0) (delete) "foo" 0) file-notify--callback-inotify)
> file-notify-handle-event (file-notify ((1 . 0) (create) "foo" 0) file-notify--callback-inotify)
> file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
> --8<---------------cut here---------------end--------------->8---
>
> The corresponding events for the file /tmp/xxx/foo are
>
> --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---
>
> As you can see, file notifications are stopped after receiving the
> 'delete' event. This is a feature of our file notifications implementation.
>
> Running "echo test >> foo" instead shows the events
>
> --8<---------------cut here---------------start------------->8---
> file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) file-notify--callback-inotify)
> file-notify-callback (1 . 0) changed "/tmp/xxx/foo" nil #s(file-notify--watch "/tmp/xxx" nil auto-revert-notify-handler) "/tmp/xxx" "/tmp/xxx"
> auto-revert-notify-handler ((1 . 0) changed "/tmp/xxx/foo")
> --8<---------------cut here---------------end--------------->8---
>
> This works as expected. So I fear there's nothing we can do.

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.

Are there any obvious flaws with this approach that I'm missing?

> Best regards, Michael.

Best regards.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#55578; Package emacs. (Tue, 24 May 2022 17:53:02 GMT) Full text and rfc822 format available.

Message #17 received at 55578 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: <miha <at> kamnitnik.top>
Cc: 55578 <at> debbugs.gnu.org
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Tue, 24 May 2022 19:52:37 +0200
<miha <at> kamnitnik.top> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#55578; Package emacs. (Tue, 24 May 2022 18:10:03 GMT) Full text and rfc822 format available.

Message #20 received at 55578 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: <miha <at> kamnitnik.top>
Cc: 55578 <at> debbugs.gnu.org
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Tue, 24 May 2022 20:09:46 +0200
Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi,

> 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'.

Oops, I've just retested. Looks like we have already this. While
polling, auto-revert-buffer checks already whether it could
(re-)activate file notification for that file.

So there's nothing left to do, right?

Best regards, Michael.




Reply sent to Michael Albinus <michael.albinus <at> gmx.de>:
You have taken responsibility. (Wed, 29 Jun 2022 13:39:02 GMT) Full text and rfc822 format available.

Notification sent to miha <at> kamnitnik.top:
bug acknowledged by developer. (Wed, 29 Jun 2022 13:39:02 GMT) Full text and rfc822 format available.

Message #25 received at 55578-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: <miha <at> kamnitnik.top>
Cc: 55578-done <at> debbugs.gnu.org
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Wed, 29 Jun 2022 15:38:28 +0200
Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi,

>> 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'.
>
> Oops, I've just retested. Looks like we have already this. While
> polling, auto-revert-buffer checks already whether it could
> (re-)activate file notification for that file.
>
> So there's nothing left to do, right?

No response for weeks, so I assume it's OK. I'm closing the bug. Feel
free to reply if you believe there're still problems.

Best regards, Michael.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 28 Jul 2022 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 245 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.