From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New file notification event `stopped' Date: Sat, 10 Oct 2015 13:28:07 +0300 Message-ID: <83vbafrpag.fsf@gnu.org> References: <87y4fsqlek.fsf@gmx.de> <87bnc7gheq.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1444473023 3924 80.91.229.3 (10 Oct 2015 10:30:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 10:30:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 12:30:14 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 1ZkrPp-00014M-F7 for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 12:30:13 +0200 Original-Received: from localhost ([::1]:44348 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrPo-0006O0-PP for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 06:30:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrPk-0006KM-2O for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:30:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkrPf-0005GA-49 for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:30:08 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:46184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkrPe-0005FS-S4 for emacs-devel@gnu.org; Sat, 10 Oct 2015 06:30:03 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NW000P001VJ4L00@mtaout25.012.net.il> for emacs-devel@gnu.org; Sat, 10 Oct 2015 13:25:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NW000N9B2AG8O30@mtaout25.012.net.il>; Sat, 10 Oct 2015 13:25:28 +0300 (IDT) In-reply-to: <87bnc7gheq.fsf@gmx.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:191115 Archived-At: > From: Michael Albinus > Date: Sat, 10 Oct 2015 12:13:49 +0200 > > 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. 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. 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. 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?