Re: Bug#335481: zsh: zsh/sched waits for next return to prompt even with NOTIFY set

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

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 <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/