Avoid waiting 10ms after normal key events #655
Conversation
Avoid waiting 10ms after normal key events, so that we process normal key events quickly when they arrive. To handle pastes and resize bursts, introduce a "busy" state. When we see events immediately ready after an event, assume it's a paste, and enter the "busy" state. Similarly, after a resize, enter the "busy" state. When the paste or resize burst appears to be done, leave the "busy" state and resume processing normal key events quickly. See the comments in the code for more details. Also, bump `POLL_WAIT` to 100ms. The previous change means we're not waiting for `POLL_WAIT` after normal keyboard input events, so we can afford to make this a little longer, and empirically, 100ms seems to be needed to avoid processing events during a resize burst on my machine. And, remove the `EVENTS_THRESHOLD`, which now apppears to be redundant. Fixes nushell#643.
|
This is a more subtle change than #651, and will take more care to confirm that it works reliably for everyone. So far, I've tested this on Linux a few different terminals. My understanding of the platform APIs used by |
Codecov Report
@@ Coverage Diff @@
## main #655 +/- ##
==========================================
- Coverage 49.21% 49.21% -0.01%
==========================================
Files 43 43
Lines 7914 7915 +1
==========================================
Hits 3895 3895
- Misses 4019 4020 +1
|
|
What's the best way to test this. I have a Mac and can help test. |
|
I tried pasting 16 lines and it's super-fast and worked great. However, when I pasted 165 lines the last 31 lines showed up in the repl and lines before that disappeared. Also, I couldn't get out of the paste mode. I hit return about 10 times and still had the multiline indicator. Seems like it wouldn't accept the line. |
|
Yeah, for testing, the main things to test are: simple typing, small and large (> 1024 bytes, which is crossterm's buffer size) pastes, and window resizing. Ideally they should all feel fast. In theory, the PR here is just changing the timing when events are processed and when repaints happen. It's possible that this is uncovering a pre-existing bug somewhere. |
|
Marking this as draft until the large paste issue is resolved. |
|
Any more thoughts on this @sunfishcode? |
|
Any updates here? |
|
No; I'm not likely to get back to this for a while now, so I'll close this. If anyone else wants to continue this, feel free to. |
Avoid waiting 10ms after normal key events, so that we process normal key events quickly when they arrive.
To handle pastes and resize bursts, introduce a "busy" state. When we see events immediately ready after an event, assume it's a paste, and enter the "busy" state. Similarly, after a resize, enter the "busy" state. When the paste or resize burst appears to be done, leave the "busy" state and resume processing normal key events quickly. See the comments in the code for more details.
Also, bump
POLL_WAITto 100ms. The previous change means we're not waiting forPOLL_WAITafter normal keyboard input events, so we can afford to make this a little longer, and empirically, 100ms seems to be needed to avoid processing events during a resize burst on my machine.And, remove the
EVENTS_THRESHOLD, which now apppears to be redundant.Fixes #643.