From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Added inotify support. Date: Wed, 03 Oct 2012 14:47:44 -0400 Message-ID: References: <2181827.T3JxG88qQt@descartes> <83lifoa7hr.fsf@gnu.org> <87obkkcu92.fsf@wanadoo.es> <83ipas9pmz.fsf@gnu.org> <83wqz78kx2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1349290098 11392 80.91.229.3 (3 Oct 2012 18:48:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2012 18:48:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 03 20:48:23 2012 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 1TJTzB-0008Tj-H3 for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 20:47:57 +0200 Original-Received: from localhost ([::1]:36184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJTz6-000589-0N for ged-emacs-devel@m.gmane.org; Wed, 03 Oct 2012 14:47:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJTz3-00057p-3r for emacs-devel@gnu.org; Wed, 03 Oct 2012 14:47:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJTz2-0004LC-2t for emacs-devel@gnu.org; Wed, 03 Oct 2012 14:47:49 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:3434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJTz0-0004Kt-HN; Wed, 03 Oct 2012 14:47:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxLQG/2dsb2JhbAA8CLQRgQiCFQEBBAFWIwULCzQSFBgNJIgcBboJix2FJwOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="200582439" Original-Received: from 69-196-180-6.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 03 Oct 2012 14:47:45 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 0272B594E8; Wed, 3 Oct 2012 14:47:44 -0400 (EDT) In-Reply-To: <83wqz78kx2.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Oct 2012 20:34:01 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:154029 Archived-At: > That said, when will this simpler interface be added? before or after > Emacs 24.3 is locked for changes? After: there is no time to design such an API before the freeze. > That's assuming the inotify support _will_ be in Emacs 24.3. I think it would be good for it to be in 24.3, mostly to get the ball rolling. > Hmmm... does this include file size? I don't know. If it doesn't, > then do I need to catch the series of IN_OPEN, IN_WRITE, IN_CLOSE? Yes, someone will have to figure that out. Leaving inotify outside of 24.3 won't save this work, tho. > For example, if you type at the shell prompt "echo foo > bar" with > 'bar' an existing non-empty file, how many notifications do you see? > On Windows, I get 2 or 3, depending on the details: 2 for size change > (first one when the file is truncated, second one when "foo" is > written into it), and sometimes also an attribute or "security" change > (e.g., if the original file was owned by someone else). Unless > inotify magically merges all these into a single meaningful > notification, the Lisp code that receives this series of notifications > will have hard time doing TRT with them, even if the exact expected > series are known in advance, especially if other notifications are > interspersed with these. Yes, but I don't see what alternative approach would save us from doing this work. > And we should talk _today_ about that API, because some of the > processing needed to produce higher-level abstractions of events are > much easier done in C than in Lisp. Ah, so that's what it's about. I don't see why that should be the case, but if it is so, then indeed we might be better off postponing the merge. Or to only include it if Emacs is compiled with some "experimental-inotify" flag. Stefan