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: Re: New file notification event `stopped' Date: Sat, 10 Oct 2015 13:56:43 +0200 Message-ID: <877fmvgcn8.fsf@gmx.de> References: <87y4fsqlek.fsf@gmx.de> <87bnc7gheq.fsf@gmx.de> <83vbafrpag.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444478233 18946 80.91.229.3 (10 Oct 2015 11:57:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 11:57:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 13:56:55 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 1Zksli-0003kX-Uy for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 13:56:55 +0200 Original-Received: from localhost ([::1]:44630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zksli-0005dO-1g for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 07:56:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zksld-0005dE-Lq for emacs-devel@gnu.org; Sat, 10 Oct 2015 07:56:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zkslc-0008Dj-MZ for emacs-devel@gnu.org; Sat, 10 Oct 2015 07:56:49 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:50407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkslY-0008Ck-Nt; Sat, 10 Oct 2015 07:56:44 -0400 Original-Received: from detlef.gmx.de ([79.195.14.202]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lu7a2-1alsuD3aA2-011SzG; Sat, 10 Oct 2015 13:56:44 +0200 In-Reply-To: <83vbafrpag.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Oct 2015 13:28:07 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:hQ2j49fSZOuwzHAkYcSdI/1tnWTAi3xRjp8L9vyXWTFpobokXd8 vxI+QszJZd7JnU18lijg/Ls1LOAquuIZAXGlVzDnOz2V3oVoWuCiJyh1IOA+0NvyKbt49ze q/rSvrOr0jGmf2oZSMPjfdHbdFauoBQHbLJ/btyLhtAKhnQBD3tVnaV5ED42VODKVzlzCJe vqzv2UoYmFuFOXTY4gp1g== X-UI-Out-Filterresults: notjunk:1;V01:K0:/jzSwu16TyU=:rSX9oIet+e2xSJtRIhks8Q YF2m0VmUKm1hXy/IEYrUJLvSEsmmUFjbb5SnzGk46ANNPnQxMuL1E6XCNCsEaaujPypmeyA+d seDCcnuwOHvykw+bcC4b/FtFVZr4sodL9+e/XONahWKEpDCJ/n5kwjWEko6h9nfpGqIU0J/WV ybJYT7tsAFNgwIwuLtNbdQyWaK2PzlJ0616qLuJIw3+cHBL13CaaOxba3finw0GUaCpVIYK+H abYIdlycFvp73VRYEvYiwffW1ulh86XFh9JKf5G1uU2Hcu2xZbZiLNu0vh69/yaovQPsW0lBg A7l/zz8Xxu/Q3h22yMl4Zmw0pxMFfcRS9Jz8Q395QYWV6omjGxwK49nWUuG8hG0aXBFEXNLHt D4fSFWWkmLV9cBCPYKepi5ptqU/uJkGb2KBQGxw4dJyocbSVFHRba45xQ05VEpctyWJzHC5oS OVSvDXpChlbLqY5Bpn9hTCkXLuACyq5CW3CGbtWTUWGJrao7NX10m4R/0XEED4iDB6IjmFo3g 2yLuqiuV1zE+Qxkd+q85bbdgNW0JuSXK30CzYHF9NwpDezyDgalnC+ThBe9EYNNNp4xeqqJvT FutYoAa6sGlR6BLatdTQZzvwCcwzSyJ7LrsI0MRg4QofxZ9W+ERd4jETNqOnYd54GPjcthKJO qNmGwV7ZXll7Gx3Rs6l2Mr+0GUwY5PglHaFijDwhuy+HshfPRm8c+tjsbGRBhWMyuYgtaEP3N fJ7L3OK1ITTZWCG4Fdftav4gOFBm3TAqANXw6HuRi32AXkrDcrAQ9W/QMV9r6YhPqBbEqxiO 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:191132 Archived-At: Eli Zaretskii writes: >> Nobody did reply. > > I did. Or I thought I did, but now I cannot find my response in the > archives. Maybe it's my imagination, or maybe it has something to do > with the recent snafu in GNU mailman archives. At least I haven't received an email from you on this topic. Usually, you Cc the sender of a message. > Anyway, my response boils down to this: I don't think we should make > notification back-ends invent events that are not reported by the > respective OS facilities. Doing that is the job of filenotify.el. D'accord. I have no specific plan yet how to implement this in the backends, maybe they could be kept untouched. I've tried to show that inotify.c sends already the needed event (`ignored'), and gfilenotify.c seems also to send useful events about (`deleted', `renamed' and `unmounted'). Maybe there is indeed nothing to do. If this is also the case for w32notify.c - even better. > In addition, I don't know how to implement this in w32notify.c, at > least not easily. As I said, when the watched directory is deleted, > the thread that watches exits with an error status, that's all. But isn't there at least the `removed' event? Or is it just for files of the watched directory, and not the directory itself? In the latter case, we would need a trigger indeed. Maybe sending an additional `removed' event for the directory could be an option? > What problem should this 'stopped' event solve? Do we really have a > real-life problem here, and if so, couldn't we solve it in some other > manner? Imagine you have a file under supervision in auto-revert-mode. If the watch is broken or removed (by a *-rm-watch call), autorevert could still work due to the polling mechanism in autorevert.el. Best regards, Michael.