This proposed solution to the macOS partial escape sequence problem can be contrasted against #158 (which is similar to another proposal from the comment thread on #132). Compared with that solution, this one is more complicated but will handle the case where an escape sequence is interrupted such that ONLY the escape character comes through ahead of the rest of the sequence. It's not proven whether that's possible since AFAICT we don't understand the mechanism by which the escape sequences are being split up in macOS, but then the whole problem here is nondeterminism.
Also this solution relies on an arbitrary delay which works according to my testing but is not verifiably "correct". This causes an short delay in processing of plain Escape keypresses. The delay is supposed to be long enough to let long escape sequences finish, but short enough not to be noticeable by the user. I have it set to 50 ms in my commit but this is obviously debatable and subject to observed behavior.
Whether this solution is better than the simpler one (if the simpler one were modified to be macOS only) I leave up to @nsf :)
Outline of this solution:
If an escape character is encountered but a full escape sequence cannot be parsed out, return a new flag to tell PollEvent to wait a bit for the rest of the sequence to come in. extract_event() now returns one of 3 states, not just a bool.
In PollEvent, set a timer and keep a reference to its underlying channel.
If we get another input event before the timer period elapses, stop and drain the timer and continue like normal.
If the timer elapses before another input event comes in, try to extract_event again, this time with the wait logic disabled so that a partial sequence will be interpreted as keypresses.
Other than on macOS, the escape wait case does not trigger, the timer remains uninitialized, and the esc_timeout channel remains nil and will never fire.
This proposed solution to the macOS partial escape sequence problem can be contrasted against #158 (which is similar to another proposal from the comment thread on #132). Compared with that solution, this one is more complicated but will handle the case where an escape sequence is interrupted such that ONLY the escape character comes through ahead of the rest of the sequence. It's not proven whether that's possible since AFAICT we don't understand the mechanism by which the escape sequences are being split up in macOS, but then the whole problem here is nondeterminism.
Also this solution relies on an arbitrary delay which works according to my testing but is not verifiably "correct". This causes an short delay in processing of plain Escape keypresses. The delay is supposed to be long enough to let long escape sequences finish, but short enough not to be noticeable by the user. I have it set to 50 ms in my commit but this is obviously debatable and subject to observed behavior.
Whether this solution is better than the simpler one (if the simpler one were modified to be macOS only) I leave up to @nsf :)
Outline of this solution: