> +1 for ANSI only.

You mean you recommend two separate SRFIs, one for POSIX and one for ANSI?

> +1  for hybrid handling of ESC, though I don't think the delay time
> needs to be tunable any more either.
I think we need to give users a choice between vi/emacs/hybrid styles.
Otherwise they can't implement an Emacs-style editor, for example.

For example, run `emacs -Q -nw` or `mg` or `uemacs`, press and release
Esc, then wait 10 seconds, then press `x`. They will faithfully wait 10
seconds for the classic "M-x" modifier key. In fact, they'll wait
forever as far as I can tell.

The specific length of the timeout in hybrid mode probably doesn't need
to be configurable. Some HCI researcher ought to be able to give a
near-optimal number. Can you name well-known programs that have hybrid
behavior? We could look in the source code for the value.

> See <https://github.com/johnwcowan/r7rs-work/blob/master/UiEvents.md>
> for my current ideas about polling terminal/mouse/graphics events.  I
> think everything you've talked about is there.

That's a valiant effort, but a UI event abstraction is going to be very
difficult. I've tried to design one several times and given up. Not only
are terminals and GUIs quite different, but there's all kinds of new and
upcoming stuff like multi-touch, pressure sensitivity, force-feedback,
N-button mouses, multiple mouse cursors, VR headsets, etc.

Given how impossible it is to map all the present stuff, let alone
anticipate future stuff, I would make the event representation per-API
and keep it simple and extensible. For terminals, I'd maybe return a
plist similar to the foreign-status thing. The list head can be a symbol
for the event type; for novel types of events a new symbol can be
coined. You can (match ...) based on the head.