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: filenotify.el Date: Tue, 25 Jun 2013 21:00:43 +0200 Message-ID: <87vc52yq04.fsf@gmx.de> References: <87d2ra9z4x.fsf@gmx.de> <1383316.4Bc292dOgY@descartes> 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 1372186860 24765 80.91.229.3 (25 Jun 2013 19:01:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 19:01:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?R=C3=BCdiger?= Sonderfeld Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 25 21:01:01 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 1UrYU4-0004YJ-Sx for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 21:00:57 +0200 Original-Received: from localhost ([::1]:54672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrYU4-0005w1-Ik for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 15:00:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrYTy-0005vv-8p for emacs-devel@gnu.org; Tue, 25 Jun 2013 15:00:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrYTw-0002UJ-Ns for emacs-devel@gnu.org; Tue, 25 Jun 2013 15:00:50 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:64323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrYTw-0002UA-8b for emacs-devel@gnu.org; Tue, 25 Jun 2013 15:00:48 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MF6gP-1V2o5d3dFL-00GLaK for ; Tue, 25 Jun 2013 21:00:46 +0200 Original-Received: (qmail invoked by alias); 25 Jun 2013 19:00:46 -0000 Original-Received: from p5B2989B6.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [91.41.137.182] by mail.gmx.net (mp034) with SMTP; 25 Jun 2013 21:00:46 +0200 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX18u+vgZ1dQudtzkBhQwdaWHjUp/YmDwgTmSyEmEwW YKNodZE0QQHClV In-Reply-To: <1383316.4Bc292dOgY@descartes> (=?utf-8?Q?=22R=C3=BCdiger?= Sonderfeld"'s message of "Tue, 25 Jun 2013 18:25 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.18 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:161040 Archived-At: R=C3=BCdiger Sonderfeld writes: > Hi, Hi R=C3=BCdiger, > I have a few comments: > > + (or (and (featurep 'gfilenotify) > + (not (featurep 'inotify)) > + (not (featurep 'w32notify))) > + (and (not (featurep 'gfilenotify)) > + (featurep 'inotify) > + (not (featurep 'w32notify))) > + (and (not (featurep 'gfilenotify)) > + (not (featurep 'inotify)) > + (featurep 'w32notify))) > > Why is the support exclusive? Just to be sure. The different low-level packages are not fully compatible (event names differ, for example); it would be a nightmare for filenotify.el when the different packages compete under the hood. In general, it could be possible to apply several low-level file notification libraries in parallel. But this wouldn't bring additional features, so we should avoid this. (Out of curiosity, I let compete file monitoring for "/tmp" and "/ssh::/tmp" in parallel. Very funny.) > Maybe we could set `file-notify-support' to the name of the low-level > feature. This would provide an easy way to identify which one is > used. Really? I don't see a serious difference between (featurep 'inotify) and (eq file-notify-support 'inotify) > + ;; Shouldn't this be `file-notify-error'? > > Yes, this would be more consistent in my opinion. If nobody objects, I will change it here as well as in the low-level packages, which use `file-error'. > + (defun file-notify-event-file1-name (event) > ... > + ((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 wi= th=20 > the COOKIE to the `moved-from' event. Just now, this function is used only for gfilenotify, event `moved'. I will remove the other two cases from that function. > + ;; Check, that event is meant for us. > + (unless (setq callback (cdr (gethash descriptor file-notify- > descriptors))) > + (signal 'filewatch-error (list "Not a valid descriptor" descripto= r))) > > I'm not sure if this should be treated as an error. There could be the c= ase=20 > that a file event is still in the queue while the watch-descriptor is rem= oved=20 > and it will still be delivered. > > But I just saw that this behaviour was also changed in `file-notify-handl= e- > event' a while ago. I think this needs a bit more discussion. I believe, that the callback function needs special care from the callee. In `auto-revert-notify-handler', I wrap the sensitive code by `ignore-errors'. For example. But I agree, this might be discussed. > + ((memq 'moved-from action) 'deleted) > + ((memq 'moved-to action) 'created) > ... > + ((eq 'renamed-from action) 'deleted) > + ((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 inst= ead.=20=20 > This should be easier to implement for all APIs. That's also my intention. But Glib's implementation does not implement this for all backends, see the comment in . The w32notify case I couldn't test yet. It is on my todo list; once there is a robust implementation for all low-level packages, we shall add a `renamed' event to be returned. > + ((memq 'move-self action) 'deleted))) > > Are you sure this is correct? If I remember correctly then inotify sets = the=20 > file name to the new file name. I'll look into it. I'll check also. > Regards > R=C3=BCdiger Best regards, Michael.