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: Wed, 26 Jun 2013 02:45:44 +0200 Message-ID: <4199085.Bycd8r9Vun@descartes> References: <87d2ra9z4x.fsf@gmx.de> <1383316.4Bc292dOgY@descartes> <87vc52yq04.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 1372207561 16445 80.91.229.3 (26 Jun 2013 00:46:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Jun 2013 00:46:01 +0000 (UTC) Cc: Michael Albinus To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 26 02:46: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 1Urds1-0000fE-2j for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2013 02:46:01 +0200 Original-Received: from localhost ([::1]:44727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Urds0-0007LA-M2 for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 20:46:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Urdrv-0007Kk-Bw for emacs-devel@gnu.org; Tue, 25 Jun 2013 20:45:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Urdrs-0005lr-ED for emacs-devel@gnu.org; Tue, 25 Jun 2013 20:45:55 -0400 Original-Received: from ptmx.org ([178.63.28.110]:34983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Urdrs-0005lf-7J for emacs-devel@gnu.org; Tue, 25 Jun 2013 20:45:52 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by ptmx.org (Postfix) with ESMTP id 27FCE21DB9; Wed, 26 Jun 2013 02:45:51 +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 7cbQPCs-M8B8; Wed, 26 Jun 2013 02:45:49 +0200 (CEST) Original-Received: from descartes.localnet (chello080108246092.7.14.vie.surfer.at [80.108.246.92]) by ptmx.org (Postfix) with ESMTPSA id 58D2321445; Wed, 26 Jun 2013 02:45:49 +0200 (CEST) User-Agent: KMail/4.10.3 (Linux/3.8.0-23-generic; KDE/4.10.3; x86_64; ; ) In-Reply-To: <87vc52yq04.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:161067 Archived-At: One minor nitpick I forgot: You should use two hyphens for functions w= hich=20 are not meant to be used by the user. I guess this should also include= `file- notify--handle-event'. It seems those symbols * file-notify-callback * file-notify-descriptors * file-notify-event-file-name * file-notify-event-file1-name * file-notify-callback should not be directly used by the user. On Tuesday 25 June 2013 21:00:43 you wrote: > 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 additiona= l > features, so we should avoid this. > > (Out of curiosity, I let compete file monitoring for "/tmp" and > "/ssh::/tmp" in parallel. Very funny.) I agree with Stefan here. I don't see a reason why Emacs couldn't be c= ompiled=20 with several filenotify APIs. Both inotify and gfilenotify are availab= le on=20 the same system. filenotify.el should of course only pick one. But it= =20 shouldn't really be affected if there are more available. > > Maybe we could set `file-notify-support' to the name of the low-lev= el > > feature. This would provide an easy way to identify which one is > > used. >=20 > Really? I don't see a serious difference between (featurep 'inotify) = and > (eq file-notify-support 'inotify) This would of course only make sense if the support isn't exclusive. > 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 this error couldn't be handled by `ignore-errors' because it happen= s=20 before the callback is called. Or am I misunderstanding you? Regards R=C3=BCdiger