From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8680 invoked from network); 8 Sep 2006 11:32:04 -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 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 11:32:04 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 78937 invoked from network); 8 Sep 2006 11:31:55 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Sep 2006 11:31:55 -0000 Received: (qmail 24961 invoked by alias); 8 Sep 2006 11:31:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22678 Received: (qmail 24951 invoked from network); 8 Sep 2006 11:31:52 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 8 Sep 2006 11:31:52 -0000 Received: (qmail 78700 invoked from network); 8 Sep 2006 11:31:52 -0000 Received: from mtaout01-winn.ispmail.ntl.com (81.103.221.47) by a.mx.sunsite.dk with SMTP; 8 Sep 2006 11:31:50 -0000 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060908113148.TMXX15018.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Fri, 8 Sep 2006 12:31:48 +0100 Received: from pwslaptop.csr.com ([81.107.41.155]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20060908113148.XTXP23938.aamtaout02-winn.ispmail.ntl.com@pwslaptop.csr.com> for ; Fri, 8 Sep 2006 12:31:48 +0100 Received: from pwslaptop.csr.com (pwslaptop.csr.com [127.0.0.1]) by pwslaptop.csr.com (8.13.7/8.13.7) with ESMTP id k88BVe5g032123 for ; Fri, 8 Sep 2006 12:31:41 +0100 Message-Id: <200609081131.k88BVe5g032123@pwslaptop.csr.com> From: Peter Stephenson To: zsh-workers@sunsite.dk Subject: Re: Bug#335481: zsh: zsh/sched waits for next return to prompt even with NOTIFY set In-Reply-To: Message from Bart Schaefer of "Thu, 07 Sep 2006 20:18:59 PDT." <060907201859.ZM14456@torch.brasslantern.com> Date: Fri, 08 Sep 2006 12:31:40 +0100 Bart Schaefer wrote: > } 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.) sched doesn't know if you're doing output to the terminal at all. > I realize this might mean that "sched" itself needs a -t option to > turn off the implicit "zle -I". Or on. That was my first thought, but I wondered if it could be made more intelligent. > 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). That looks like a problem. Maybe it needs to be an option to sched, in that case; that's the simplest thing to do and I'll change it. Of course you can use a function with zle -I in it, but that makes using sched for simple output a little too difficult. > Also, it's unclear whether "echo" is affected by the change to "print"? Currently it is (and this is documented under "print -t", but not for "echo" itself), but it doesn't need to be. This will go away if I move the behaviour to sched. > } 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. I haven't change any key timeout at all, I've changed the *limit*. It's now long enough for any conceivable use of a key timeout. The 5 second limit was arbitrary but arguably not long enough for any *conceivable* use. The change doesn't show up unless you set KEYTIMEOUT to something more than 500. This saves me from having two different limits built into the code since I need one for restarting the timeout for sched events long in the future (which are probably atypical but there's no good reason why they shouldn't work). > } 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? I didn't see a good use for this, but it's not a very difficult change. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/