From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26306 invoked from network); 8 Sep 2006 03:19:34 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 8 Sep 2006 03:19:34 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 78745 invoked from network); 8 Sep 2006 03:19:28 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Sep 2006 03:19:28 -0000 Received: (qmail 11021 invoked by alias); 8 Sep 2006 03:19:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22677 Received: (qmail 11012 invoked from network); 8 Sep 2006 03:19:25 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 8 Sep 2006 03:19:25 -0000 Received: (qmail 78480 invoked from network); 8 Sep 2006 03:19:25 -0000 Received: from vms044pub.verizon.net (206.46.252.44) by a.mx.sunsite.dk with SMTP; 8 Sep 2006 03:19:23 -0000 Received: from torch.brasslantern.com ([71.116.118.106]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J5900DZO7VO6AG1@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Thu, 07 Sep 2006 22:19:01 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id k883IxxY014458 for ; Thu, 07 Sep 2006 20:18:59 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id k883Ixg7014457 for zsh-workers@sunsite.dk; Thu, 07 Sep 2006 20:18:59 -0700 Date: Thu, 07 Sep 2006 20:18:59 -0700 From: Bart Schaefer Subject: Re: Bug#335481: zsh: zsh/sched waits for next return to prompt even with NOTIFY set In-reply-to: <20060907202542.4927510e.p.w.stephenson@ntlworld.com> To: zsh-workers@sunsite.dk Message-id: <060907201859.ZM14456@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20060907202542.4927510e.p.w.stephenson@ntlworld.com> Comments: In reply to Peter Stephenson "Re: Bug#335481: zsh: zsh/sched waits for next return to prompt even with NOTIFY set" (Sep 7, 8:25pm) On Sep 7, 8:25pm, Peter Stephenson wrote: } } I got a chance to look at it. As we already do quite sophisticated } things while the line editor is waiting for shell input (key timeouts } and polling of file descriptors) it's not so difficult to expand this so } that a sched timer can fire at this point. I haven't looked at } extending this to be fully asynchronous: it's not clear you want that It's pretty clear to me that one *doesn't*, actually. What would be a useful alternative is to be able to do something like (sched 01:05 print "It's 1:05 AM, go to bed")& and have the subshell hang around until either the parent shell exits or the scheduled time arrives. That probably needs an option to the sched command, perhaps -w (for wait) or -s (for sleep). If this were possible, maybe a lot of the other changes you made wouldn't be necessary, but ... } sched events will now fire while waiting for user input in zle. Presumably this means they behave as if prefixed with "zle -I". I see that you've made "print" intelligent in this way, but what if the sched job invokes an external command that outputs to the terminal? Why shouldn't "sched" be what takes care of "zle -I" rather than having it built into "print"? (Given a choice of directions, I'd rather make the main shell less aware of ZLE rather than more.) I realize this might mean that "sched" itself needs a -t option to turn off the implicit "zle -I". Jumping ahead a bit: } The only problem with this I can see is if the "print" is only being } used, say, to update a terminal emulator title bar, and the likely of } doing that at a point where you want to make it invisible to the user } that a function is being run isn't that great anyway so I can't see a } reason why this shouldn't be the default. I update a clock in my title bar with a TRAPALRM function, and in fact I'd suspect that this is the sort of thing for which lots of people would rather use sched if it had always worked the way this patch changes it to work. I confess I'm not precisely clear whether that falls under the category of "print"s that would or would not need -t, but I'd be unhappy to have the default stop behaving the way I expect (and the way it has behaved for me now for lo-these-many-years). Also, it's unclear whether "echo" is affected by the change to "print"? } As a side effect of the new mechanism I've upped the arbitrary limit on } key timeouts, which used to be 5 seconds, to (typically) 24 days, which } ought to be long enough Long enough for what? I'm stumped as to the rationale for this. If it's because the scheduled task might begin doing something for a long time right in the middle of key sequence, I think it would make much more sense to keep the key timeout short and prevent processing sched items during the wait for the "rest" of a sequence. } sched now accepts a number of seconds (when there's no ":" in the time) This is nice, so why not also allow it to accept HH:MM:SS too? } Internally, I've done the following: Those all sound like worthwhile improvements to me.