WIP: autorun with delay#41
Conversation
|
❤️ Thanks a lot for the PR! I will try to find some time to test and review it, though I could not manage to do that yet. |
|
|
||
| event := tui.PollEvent() | ||
| if autoRunTimer != nil { | ||
| autoRunTimer.Stop() |
There was a problem hiding this comment.
Hmm; I think as is now, this will get the autorun cancelled when triggerRefresh is called, no? I think this results in weird semantics, where slow input can delay the autorun; maybe the timer should be stopped only in case *tcell.Key: ?
| if command != lastCommand && autoRunDelay > 0 { | ||
| autoRunTimer = time.AfterFunc(autoRunDelay, func() { | ||
| log.Println("Firing interrupt - poll timed out") | ||
| tui.PostEvent(tcell.NewEventInterrupt("autoRunTimer")) |
There was a problem hiding this comment.
Mwahaha! I just realized we can probably do a sneaky hack here, by replacing NewEventInterrupt with NewEventKey(tcell.KeyEnter, ...); this should let us remove the whole l.201-207 block!
|
I just compiled and run it for a test drive. I think this is pure awesome!!! 😄 I'm totally for adding this feature. Let's go with a regular review. Apart from the comments I already added, one thing I'm somewhat worried about is a possible race between the autoRun "interrupt" and a "real" key pressed by user. Such that we Poll and start processing a real key, but before we managed to Stop the timer, it's already fired and enqueued a new "interrupt". It's not 100% clear to me if and how this can be avoided; but I am starting to have some initial intuition that it might be possible. Though it might require backing off from the "NewEventKey(KeyEnter,...)" hack. edit: Or maybe not? There could be some counter of KeyEnters to ignore... ehh, anyway, currently I think this "avoidance" will be a tad bit ugly anyway. |
2 participants
No description provided.