From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: New file notification event `stopped' Date: Sun, 27 Sep 2015 11:08:51 +0200 Message-ID: <87y4fsqlek.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1443344984 12643 80.91.229.3 (27 Sep 2015 09:09:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2015 09:09:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 27 11:09:28 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zg7xH-00005n-5p for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2015 11:09:11 +0200 Original-Received: from localhost ([::1]:56649 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg7xG-0006zW-Jm for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2015 05:09:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg7x4-0006zF-6r for emacs-devel@gnu.org; Sun, 27 Sep 2015 05:08:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zg7x0-00062T-78 for emacs-devel@gnu.org; Sun, 27 Sep 2015 05:08:58 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:52439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zg7x0-00061z-00 for emacs-devel@gnu.org; Sun, 27 Sep 2015 05:08:54 -0400 Original-Received: from detlef.gmx.de ([87.146.44.95]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0McEkx-1ZvsDT0KSl-00Jc55 for ; Sun, 27 Sep 2015 11:08:52 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:zy3O5hVq6URzS45rej2o6EANNwIk8tbF65qrwOv8/ifSmOjYOtS ZNtwLLOaboQD9Mlr7FzJYE8NStqQ6LkjqNYvLn10hNgwTW2tHH2my1uTsCbJS+3IEcg4Gnt POJm4tIrpMEZi3Is2aZc2NA6KQpNTbozSAcDhQO12XJrU9KXTNkh0uQB+Mbw39HEIktp6uO cDjtNwkFV/wGuaerlcqnw== X-UI-Out-Filterresults: notjunk:1;V01:K0:liCjCZ+FG6o=:4jMzaZlmUw1O0FmHcNoEGp rZ5uKCEziMYYM8N9nQJXhjUkT+L5SBBcfKjnVO3IcWwG2D5TLxL/0HN7tyvGni/ZCcUmgoDzZ qeOj30A/Qpcyp576lwfKcegChBghHdxKaRnWgreN5ZsKFcRnuCJqcRYlF53KA2FCDdiUFz00b An1ot2wqDCsdfwDsPnvkDhvbRYyf6FgMiNbTa0ybEvPalO2km+WnuI5hnHuq4LG7ovpv3uu+3 zVLwAcCJzDI8CkEYJwVGmI8F0tSS0B7S9RN3OZuuEUpXOpJ0neC3IOdE0SM1Snni3yXYNmDLE vNd7jRZZSg3J/qdo+Jnjg+vXkP+BbVLheoba6fF/EjQvPePfVJNI5z2OL1GTT14XH+BrycJMs pugpCPoy6J1PJTHl2mGDB6+g6qa9Zhy2JMzNiXmxLBfEXlXSvPyB5+wkgWGZfiWf/m3Nrj7Ow wOXqaJUdHaicKiosHE8lnUkZ3Zmv4kkjMBrA9WxU7lm5u9uD5ZZIT91pMKk9xSf7hakf0SeEE xqoKtjzpFHQNqcWECGNgBPUprhEkrKj558ybclqIUQ4bKgzszYyTQvipRs//xQrL3IjFQEiqH chELWtXSp31SUxczm/SZ9HXR6AaV8mfzllIAj7zywN/y20Dr5icB/qhPgGClzsVSbgLhn0iI+ njJOky6cs4Fn5kDHOohdd0Md6qCxg7AkxA0AZucJQJnGobF6blSdYkOl2zotQlmz/LITAMvIQ jZhMh+sXeM+uF8WAodwTZH4cuolLXUtKdSdHkg== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.15 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190396 Archived-At: Hi, during the work on bug#21432 and bug#21435, we have introduced a new function `file-notify-valid-p', which tells whether a given monitor is still active. We have also discussed shortly, whether a monitor should signal, when it stops its activities. A monitor could cease to work for different reasons, maybe because it is cancelled (not only by `file-notify-rm-watch'), maybe because the file/directory to be watched is deleted, maybe because some internal limits are reached. Therefore, I propose that a new file notification event `stopped' shall be added to the file notification events to be raised by a file notification monitor. This would allow applications to react directly on this situation. For example, `auto-revert-mode' could switch to polling then. The implementation for inotify.c is simple, because it receives already the native IN_IGNORED event in this case, which could be mapped easily to the `stopped' event. The implementation for gfilenotify.c would create such a `stopped' event, if one of the native events G_FILE_MONITOR_EVENT_DELETED, G_FILE_MONITOR_EVENT_RENAMED or G_FILE_MONITOR_EVENT_UNMOUNTED was received, and the file argument is equal to the watched file or directory. I hope a simlar mechanism could be implemented for w32notify.c. Comments? Best regards, Michael.