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: [PATCH] Added basic file system watching support. Date: Tue, 11 Dec 2012 11:39:15 +0200 Message-ID: <83ehix9bcs.fsf@gnu.org> References: <6218185.ViukoKRdFp@descartes> <1604303.YKOVcvQH0F@descartes> <8738zd6n1t.fsf@gmx.de> <83ip899fd7.fsf@gnu.org> <87y5h557cx.fsf@gmx.de> <83fw3d9elh.fsf@gnu.org> <87pq2h5660.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1355218810 14696 80.91.229.3 (11 Dec 2012 09:40:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2012 09:40:10 +0000 (UTC) Cc: ruediger@c-plusplus.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, sdl.web@gmail.com To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 10:40:21 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 1TiMK0-0007ej-9z for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2012 10:40:16 +0100 Original-Received: from localhost ([::1]:48512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiMJn-0007yu-Gd for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2012 04:40:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiMJh-0007yP-OH for emacs-devel@gnu.org; Tue, 11 Dec 2012 04:40:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiMJb-0001zf-JF for emacs-devel@gnu.org; Tue, 11 Dec 2012 04:39:57 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:37977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiMJb-0001zZ-BB for emacs-devel@gnu.org; Tue, 11 Dec 2012 04:39:51 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MEV00900112LD00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 11 Dec 2012 11:39:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEV009YC1HLJ050@a-mtaout21.012.net.il>; Tue, 11 Dec 2012 11:39:22 +0200 (IST) In-reply-to: <87pq2h5660.fsf@gmx.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:155460 Archived-At: > From: Michael Albinus > Cc: monnier@iro.umontreal.ca, ruediger@c-plusplus.de, sdl.web@gmail.com, emacs-devel@gnu.org > Date: Tue, 11 Dec 2012 09:44:55 +0100 > > Eli Zaretskii writes: > > > Then Tramp could maintain its own data structure for watched files, > > and give each watch a unique identifier, like (FILENAME . NUMBER), or > > just NUMBER, or whatever. > > That I do already in my inotify-add-watch handler. Of course. > > > IOW, the DESCRIPTOR is an opaque data type, which the implementation > > back-end, and the back-end alone, can and should interpret. > > The point is, that something must trigger Tramp. In inotify-add-watch, I > have added the following code (shortened, there's more): Sorry, I misunderstood the issue. See below. > --8<---------------cut here---------------start------------->8--- > /* If the file name has special constructs in it, > call the corresponding file handler. */ > handler = Ffind_file_name_handler (file_name, Qinotify_add_watch); > if (!NILP (handler)) > { > return call4 (handler, Qinotify_add_watch, file_name, aspect, > callback); > } > --8<---------------cut here---------------end--------------->8--- > > In inotify-rm-watch I couldn't add similar lines, because file_name is > unknown. My proposal is either to add file_name as first argument of > inotify-rm-watch, or to declare WATCH-DESCRIPTOR as a cons cell, which > car is always the file name. IMO, this design is wrong. Tramp is just one more back-end for this feature, in addition to two others: inotify and w32notify. So I think Tramp handlers should be called from a higher-level code, one that calls whichever back-end is appropriate. Otherwise, we will need to implement the Tramp support twice, in 2 different sets of primitives. Which, of course, goes back to the kind of design discussion I suggested to have at the time, where we were supposed to consider various alternatives and eventually agree on some higher-level APIs. Jumping to coding right away is IMO not the right way. E.g., currently there are subtle but very real differences between the 2 back-ends: w32notify doesn't accept t or a lone symbol as the 2nd argument (it insists on getting a list); the list of supported watch types is entirely different; and the w32 back-ends actually watches the entire directory of the file, not just that file. IOW, this feature is not really ready for Tramp-ization, or for user-land in general. Stefan wanted people to experiment with this and gather experience, before we know enough to discuss how to make it user- and Lisp-friendly.