From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.devel Subject: Re: Emacs inotify support? Date: Sat, 12 Sep 2009 19:26:14 +0200 Message-ID: <6fa54e4e0909121026t797ee747yc2ac395314c3cc40@mail.gmail.com> References: <6fa54e4e0909111554g4165418albbdffc142b3b52ee@mail.gmail.com> <83tyz8z3sl.fsf@gnu.org> <6fa54e4e0909120936s24634600sf00a818aabd308ce@mail.gmail.com> <83r5ucyuf0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636833dfcc9ec93047364ba46 X-Trace: ger.gmane.org 1252776393 28676 80.91.229.12 (12 Sep 2009 17:26:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2009 17:26:33 +0000 (UTC) Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 12 19:26:26 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MmWMi-00013I-V7 for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2009 19:26:25 +0200 Original-Received: from localhost ([127.0.0.1]:35625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmWMi-0008Qg-Ah for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2009 13:26:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MmWMc-0008OH-VS for emacs-devel@gnu.org; Sat, 12 Sep 2009 13:26:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MmWMc-0008O5-11 for emacs-devel@gnu.org; Sat, 12 Sep 2009 13:26:18 -0400 Original-Received: from [199.232.76.173] (port=37285 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmWMb-0008O2-R6 for emacs-devel@gnu.org; Sat, 12 Sep 2009 13:26:17 -0400 Original-Received: from qw-out-1920.google.com ([74.125.92.148]:34424) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MmWMZ-0003kV-Hj; Sat, 12 Sep 2009 13:26:15 -0400 Original-Received: by qw-out-1920.google.com with SMTP id 5so722330qwf.24 for ; Sat, 12 Sep 2009 10:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=722GghmzxSUW0loobq5ucGApq6ccNE6vdqME6s+he8o=; b=L0J74Oj7bDX+60ya2bAXFSOFi0POPEe0TtaPO/LZAcM7NXDYwGQ0BFAUow0KSVucRj WK5Swhr4FiUUQhvjYgoarlOagrfX4zCNH0TGiI4fba7TnoFdh4OMP/c0jyO+fTNUt/GD +q2WEwJKsbhUroyy9v8o+T78Fiylw2vX4f9Aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=fbdQ/maRccFFCzGqbGmt7MjQP+7ULZN5utJ0NcTueoW/aYTGuETymYqsXpw2YkxbXw GCEGaUEaYL6U+cxuOuq9pFLDuVHSDE/ugGm/urkatmeMWXFo+RrFI/chfB7+aKMHf2KX Ic+WT/EhII6DSJ2u8RUL4Q3PUb5+PaGBs5ZPw= Original-Received: by 10.229.29.148 with SMTP id q20mr1597075qcc.51.1252776374561; Sat, 12 Sep 2009 10:26:14 -0700 (PDT) In-Reply-To: <83r5ucyuf0.fsf@gnu.org> X-Google-Sender-Auth: b1a0668465cfa695 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115238 Archived-At: --001636833dfcc9ec93047364ba46 Content-Type: text/plain; charset=ISO-8859-1 > > Date: Sat, 12 Sep 2009 18:36:47 +0200 > > From: Antoine Levitt > > Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org > > > > If possible, polling should be avoided, though. > > Why? Well, I don't know much about file systems, but isn't it always better to be notified than to poll ? First, having a notification system means it's instantaneous. Second, I'd imagine querying the state of a file has a cost (especially if it can't be cached and needs a real access to the hard drive). Third, it'd avoid a waste of CPU resources (which may be important for power consumption, since, from what I understood, the more a program has fixed timers, the more it wakes the CPU from sleep). Fourth, being notified is more high-level, since the notification itself can be implemented by polling. One could imagine a notification API where the backend would use inotify if available, polling if not. > But it could also be a pain in the neck to have these changes occur > while you're moving around in the Dired buffer and making changes. Agreed. Maybe couple it with a condition like "the user hasn't done anything to the buffer for n seconds" ? I also agree that notification for files shouldn't be turned on by default. When dealing with files that are modified in more than one place at the same time, the simpler and safer the default is, the better. It would be interesting to provide the feature for advanced users though (ie users who know what they want). In any case, an inotify API could be a nice basis for customisation/other modes (kinda like the dbus interface) --001636833dfcc9ec93047364ba46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > > Date: Sat, 12 Sep 2009 18:36:47 +0200
> > From: Antoine = Levitt <antoine.levitt@gmail= .com>
> > Cc: = lennart.borgman@gmail.com, joakim@v= erona.se, emacs-devel@gnu.org
> >
> > If possible, polling should be avoided, though.
&= gt;
> Why?

Well, I don't know much about file systems, bu= t isn't it always better
to be notified than to poll ?=A0 First, hav= ing a notification system
means it's instantaneous. Second, I'd imagine querying the state of= a
file has a cost (especially if it can't be cached and needs a rea= l
access to the hard drive). Third, it'd avoid a waste of CPU resour= ces
(which may be important for power consumption, since, from what I
unders= tood, the more a program has fixed timers, the more it wakes the
CPU fro= m sleep). Fourth, being notified is more high-level, since the
notificat= ion itself can be implemented by polling. One could imagine a
notification API where the backend would use inotify if available,
polli= ng if not.

> But it could also be a pain in the neck to have thes= e changes occur
> while you're moving around in the Dired buffer = and making changes.

Agreed. Maybe couple it with a condition like "the user hasn't= done
anything to the buffer for n seconds" ?

I also agree t= hat notification for files shouldn't be turned on by
default. When d= ealing with files that are modified in more than one
place at the same time, the simpler and safer the default is, the
bette= r. It would=A0 be interesting to provide the feature for advanced users tho= ugh (ie users who know what they want). In any case, an inotify API could b= e a nice basis for customisation/other modes (kinda like the dbus interface= )
--001636833dfcc9ec93047364ba46--