From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: idledo.el v. 0.3 Date: 24 Oct 2002 17:05:39 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xznt3op18.fsf@kfs2.cua.dk> References: <87wuobakqz.fsf@computer.localdomain> <5xfzuyqbxo.fsf@kfs2.cua.dk> <874rbduxdf.fsf@computer.localdomain> <5xbs5ljj6s.fsf@kfs2.cua.dk> <87u1jcq1ex.fsf@computer.localdomain> <5xy98ozpfj.fsf@kfs2.cua.dk> <87bs5kbuzm.fsf@computer.localdomain> <5xadl4p0xp.fsf@kfs2.cua.dk> <8765vshwgx.fsf@computer.localdomain> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035468463 15475 80.91.224.249 (24 Oct 2002 14:07:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 24 Oct 2002 14:07:43 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 184ieD-00041J-00 for ; Thu, 24 Oct 2002 16:07:41 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 184igP-0006JN-00 for ; Thu, 24 Oct 2002 16:09:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 184icq-0001cr-00; Thu, 24 Oct 2002 10:06:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 184icB-0000wi-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 10:05:35 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 184ic7-0000vp-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 10:05:34 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10) id 184ic7-0000um-00 for emacs-devel@gnu.org; Thu, 24 Oct 2002 10:05:31 -0400 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 943DE7C017; Thu, 24 Oct 2002 14:05:29 +0000 (GMT) Original-To: "D. Goel" In-Reply-To: <8765vshwgx.fsf@computer.localdomain> Original-Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8734 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8734 "D. Goel" writes: > Indeed. Your proposal does cover all useful cases. I like it! Good. > > > > Yes, it is true that with my proposal it is not possible to specify > > an idle timer which is repeated while emacs remains idle, but does > > not get repeated the next time emacs becomes idle --- but again, I > > really don't see much use for that functionality either. > > IMHO, This one is the only "important" case that does not get covered. > Though it may seldom be needed in practice, it would seem awkward to > leave this out. I honestly fail to see how that is of any practical use. But it could be handled by overloading the REPEAT argument so that if it is a negative number, it means repeat every -REPEAT seconds after first being idle, but don't repeat on next emacs idle. > However, a user who does want to implement the "missing" functionality > will again do weird stuff, as done in blink-cursor-mode and idledo.el. Yes, that's always a possibility ... actually, it would seem to be useful to also have a "no longer idle" handler for an idle-timer which would be called for the idle-timers which have been activated; for the blinking cursor case it could be used (instead of the pre-command-hook) to restore the visible cursor state. > OTOH, the user can cleanly implement the missing functionality if one > would provide one or more of the following variables. (I guess one > could also provide appropriate hooks instead of variables.) > > idle-timer-idle-counter > "When running an idle-timer, this variable is (temporarily) bound to > the number of times the idle-timer has been triggered by emacs going idle.. " > > idle-timer-repeat-counter > "when running an idle-timer, this variable is temporarily bound to > the number of times the idle-timer has been triggered , either by > emacs going idle, or by emacs remaining idle. " > I'm not sure how these are useful in general, and I don't see why a specific idle-timer which needs this information cannot implement them locally [also, the information is currently not available anywhere]. I suppose your primary interest is to be able to know whether a given idle-timer is activated for the first time after emacs becoming idle, or whether it is a repeated activation in the same idle period; for that purpose, the first element of the timer vector could provide the necessary information (as it would be t on first invocation). Or we could modify the basic timer implementation (it is currently an 8 element vector) by adding more elements to implement the various features discussed above. In any case, it cannot be done without some changes to the interpretation of the fields of that vector, so it might just as well be extended if that makes the implementation simpler and cleaner. WDYT ? Is this something to pursue further, or should we be satisfied with the current "work-arounds" ? -- Kim F. Storm http://www.cua.dk