--- Begin Message ---
|
Subject: |
24.5; win32 file-notify, input events caused by updates to other (non-watched) files |
|
Date: |
Sun, 24 Jan 2016 03:10:38 -0500 |
Save the lisp code below to a file in a git checkout, and run it with
'emacs -Q -l file-notify-and-sit-for-test.el'. It causes Emacs to get
stuck in an infinite loop (you can exit with C-g). It seems that the
'git update-index --refresh' writes to somes files in .git/ which
triggers a file notify event (even though Emacs is not watching those
files). This causes 'sit-for' to return immediately, and the
process-status of 'git --version' never gets set to 'exit' (even though
the actual process does exit quickly).
This does not occur on GNU/Linux systems. I'm not sure if it should
be considered a bug, or just an inherent limitation of Windows' file
notification API.
The original context for this was a magit bug, since fixed by changing
to sleep-for (and hopefully will soon be better fixed by using
call-process-region instead of start-process + busy wait):
https://github.com/magit/magit/issues/2454
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Begin file-notify-and-sit-for-test.el
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(require 'filenotify)
;; simulate the problematic effect of `global-auto-revert-mode'
(file-notify-add-watch load-file-name '(change) #'ignore)
(call-process "git" nil nil nil "update-index" "--refresh")
(let ((proc (start-process "git version" nil "git" "--version")))
(message "waiting for %s" (process-id proc))
(while (eq (process-status proc) 'run)
(sit-for 0.1)
(message "waiting for %s" (process-id proc))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; End file-notify-and-sit-for-test.el
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#22454: 24.5; win32 file-notify, input events caused by updates to other (non-watched) files |
|
Date: |
Sun, 24 Jan 2016 11:46:14 -0500 |
On Sun, Jan 24, 2016 at 10:20 AM, Eli Zaretskii <address@hidden> wrote:
> When you ask to watch a file, file-notify-add-watch actually watches
> the entire directory of that file
Oh. In this case I thought it was only files beneath .git/ that were
being changed (while we we are watching a file in the working copy),
but (trace-function 'file-notify-callback) tells me that Emacs is
receiving events about the .git/ directory.
>> This does not occur on GNU/Linux systems.
>
> Did those systems use inotify or the gfilenotify back-end?
I think gfilenotify, but I only have access to a Windows box for the
next couple of weeks, so I'm not 100% sure.
> I don't think it's either a bug or a limitation. File notifications
> generate input events, so the current implementation of sit-for has a
> good reason to stop waiting. The way the input events are generated
> differ between different back-ends, so perhaps the difference in
> behavior you see is due to that, but in general I think the fact that
> you didn't see that on GNU/Linux is more luck than anything else.
Ok, sounds like there is nothing to fix on the Emacs side, so I'm closing this.
--- End Message ---