Zsh Mailing List Archive
Messages sorted by:
Re: Bug#335481: zsh: zsh/sched waits for next return to prompt even with NOTIFY set
- X-seq: zsh-workers 22678
- From: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Bug#335481: zsh: zsh/sched waits for next return to prompt even with NOTIFY set
- Date: Fri, 08 Sep 2006 12:31:40 +0100
- In-reply-to: Message from Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> of "Thu, 07 Sep 2006 20:18:59 PDT." <060907201859.ZM14456@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
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
> 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 <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/
Messages sorted by: