From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?R=FCdiger?= Sonderfeld Newsgroups: gmane.emacs.devel Subject: Re: filenotify.el Date: Tue, 25 Jun 2013 18:25 +0200 Message-ID: <1383316.4Bc292dOgY@descartes> References: <87d2ra9z4x.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372177532 15994 80.91.229.3 (25 Jun 2013 16:25:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 16:25:32 +0000 (UTC) Cc: Michael Albinus To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 25 18:25:33 2013 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 1UrW3e-000707-15 for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 18:25:30 +0200 Original-Received: from localhost ([::1]:48813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrW3d-0000WW-Ju for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 12:25:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrW3R-0000Fg-LB for emacs-devel@gnu.org; Tue, 25 Jun 2013 12:25:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrW3J-0001si-BA for emacs-devel@gnu.org; Tue, 25 Jun 2013 12:25:17 -0400 Original-Received: from ptmx.org ([178.63.28.110]:55332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrW3I-0001rt-W8 for emacs-devel@gnu.org; Tue, 25 Jun 2013 12:25:09 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by ptmx.org (Postfix) with ESMTP id 5472121445; Tue, 25 Jun 2013 18:25:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ptmx.org Original-Received: from ptmx.org ([127.0.0.1]) by localhost (ptmx.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7bwoZU4dqoT; Tue, 25 Jun 2013 18:25:05 +0200 (CEST) Original-Received: from descartes.localnet (chello080108246092.7.14.vie.surfer.at [80.108.246.92]) by ptmx.org (Postfix) with ESMTPSA id 38E0C21C95; Tue, 25 Jun 2013 18:25:05 +0200 (CEST) User-Agent: KMail/4.10.3 (Linux/3.8.0-23-generic; KDE/4.10.3; x86_64; ; ) In-Reply-To: <87d2ra9z4x.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 178.63.28.110 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:161031 Archived-At: Hi, On Tuesday 25 June 2013 14:02:38 Michael Albinus wrote: > I have written filenotify.el, which is intended as upper layer for > gfilenotify.c, inotify.c and w32notify.c. This is a simplified > interface, which offers just file change or file attribute change > notifications. I believe this is sufficient for the use-cases in Emac= s; > if more fine granular notifications are needed, one could still use o= ne > of the low-level packages. Thanks for your work so far. I agree for the upper layer portability i= s most=20 important and not fine granularity. > Beside further tests and bug fixing, I plan to write ert tests as wel= l > as a Tramp file name handler. Documentation is also lacking. But thes= e > steps could be applied later, once there is an agreement about the > interface. Yes, absolutely. There is a very basic test for inotify which could be= =20 adopted. > Comments? I have a few comments: + (or (and (featurep 'gfilenotify) + =09 (not (featurep 'inotify)) + =09 (not (featurep 'w32notify))) + (and (not (featurep 'gfilenotify)) + =09 (featurep 'inotify) + =09 (not (featurep 'w32notify))) + (and (not (featurep 'gfilenotify)) + =09 (not (featurep 'inotify)) + =09 (featurep 'w32notify))) Why is the support exclusive? Maybe we could set `file-notify-support' to the name of the low-level f= eature. =20 This would provide an easy way to identify which one is used. + ;; Shouldn't this be `file-notify-error'? Yes, this would be more consistent in my opinion. + (defun file-notify-event-file1-name (event) ... + =09((featurep 'inotify) (nth 4 event)) The event layout for inotify is (WATCH-DESCRIPTOR ASPECTS COOKIE NAME).= The=20 new file name will be NAME in the `moved-to' event and it is connected = with=20 the COOKIE to the `moved-from' event. + ;; Check, that event is meant for us. + (unless (setq callback (cdr (gethash descriptor file-notify- descriptors))) + (signal 'filewatch-error (list "Not a valid descriptor" descrip= tor))) I'm not sure if this should be treated as an error. There could be the= case=20 that a file event is still in the queue while the watch-descriptor is r= emoved=20 and it will still be delivered. But I just saw that this behaviour was also changed in `file-notify-han= dle- event' a while ago. I think this needs a bit more discussion. + =09 ((memq 'moved-from action) 'deleted) + =09 ((memq 'moved-to action) 'created) ... + =09 ((eq 'renamed-from action) 'deleted) + =09 ((eq 'renamed-to action) 'created))))) ... + ;; Apply callback. + (when (and (stringp file) (eq action 'moved)) + (funcall callback (list descriptor 'deleted file)) + (setq action 'created file file1)) + (when (and (stringp file) action) + (funcall callback (list descriptor action file))))) I don't think this is very useful because there is no way for the user = to=20 connect both events. Inotify provides COOKIE to do this. Maybe we should introduce a moved-from/moved-to event using a cookie in= stead. =20 This should be easier to implement for all APIs. + =09 ((memq 'move-self action) 'deleted))) Are you sure this is correct? If I remember correctly then inotify set= s the=20 file name to the new file name. I'll look into it. Regards R=C3=BCdiger