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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.