> John selected a set of POSIX procedures from scsh to add, see:
>
> https://srfi-email.schemers.org/srfi-205/msg/14647343/

I don't understand the above part of Unix, but seems ok.

>> (terminal-get-size) => (width . height)
>>
>>       struct winsize ws;
>>       ioctl(fd, TIOCGWINSZ, &ws);
>>       return cons(ws.ws_col, ws.ws_row);
>
> A simple call to ioctl definitely fits.

That stuff is probably not POSIX, but should be almost ubiquitous.

> Normally I'd say this doesn't fit, but ANSI is pretty much universal
> today, isn't it?  No UNIX(TM) termcap/terminfo facility needed to
> support a vast array of terminal control codes?

Yes, ANSI and many extensions are practically universal, to the extent
that any terminal emulator that didn't support that stuff would be
painful for real work.

The big exception is the Windows console, which doesn't speak any ANSI
codes unless you install a third-party ANSI.SYS driver. The console API
looks like a normal C API and is fundamentally sane, but its features
are quite limited and Microsoft is now giving in and adding ANSI
emulation with their Linux support. I don't know whether ANSI will be
always enabled in console windows, or only in special Linux windows.

termcap/terminfo are fundamentally problematic since they are standalone
databases; the information in the database isn't vetted by the terminal
emulators that the database is supposed to represent. As a result, the
termcap/terminfo databases installed onto computers commonly contain
errors and omissions, easily get out of sync. The system is also quite
complex for something that doesn't even solve the problem properly.

Hence I'd agree with your call and keep termcap/terminfo to a separate
library/SRFI for those who want it.

> So while not POSIX as far as I know, I can see adding the above
> primitives as convenience procedures, and a new title "POSIX and
> ANSI terminal primitives."
>
> Anything that will be supplied in portable Scheme in one or more
> sample implementations should ease the burden on an implementor, and
> that should cover everything with knowledge of ANSI codes.  Creating
> an "ANSI terminal primitives" SRFI would also be logical, and probably
> better to keep each to bite sized chunks; I solicit advice about
> proper SRFI scoping.

Good thinking. The ANSI stuff is really just string I/O. The stuff that
needs C-level glue is mainly `terminal-read-event`. It needs to:

- do normal blocking reads (wait infinitely or until interrupted)
   for up to N characters (buffer up an escape code or a keypress)

- do a low-level Unix read() system call with a buffer size of
   only 1 byte.

- probably handle non-blocking fd's -- my memory is fuzzy.

- deal with timeouts using poll() or similar

So definitely not stuff that is fun and portable to do in Scheme.

>>       Event types:
>>       'control
>>       'escape
>>       'resize
>>       'char

Forgot mouse events from this list. They should be supported natively,
mouse support is very common.

>>       Different ways to treat Esc:
>>
>>       0      return immediately with a standalone esc, like vi
>>       >0     wait N milliseconds for another key
>>       #f     wait forever for another key, like emacs
>
> I believe this can supplied by running your application inside
> with-raw-mode, or with-rare-mode if you don't need timeouts.

You do need timeouts eventually. But it should be enough if they are
baked into `terminal-read-event`; apart from that routine, I don't think
user code needs to be concerned with them.