> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Thursday, August 06, 2020 7:03 AM
>
> What's the scope of SRFI 205? The current first draft is nice and
> simple, and probably good as it is.

While I haven't examined them closely (right now this SRFI is subject
to benign neglect while we for example nail down enough of SRFI 198 to
finalize the eternally in draft status SRFI 170), John selected a set
of POSIX procedures from scsh to add, see:

https://srfi-email.schemers.org/srfi-205/msg/14647343/

> I designed a minimal API for dealing with ANSI terminal on Unix-like
> systems a year or two ago. It's designed to read and write things from
> and to the terminal....

This remit of this SRFI includes supplying everything POSIX that an
ANSI terminal API like your's would require; thanks for bringing it up!
So of what you supplied of it's API:

> Below is roughly what it looks like. Let me know if you want something
> at this level of abstraction in this SRFI, or if you want to keep it
> simpler.
>
> (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.

> (terminal-write-char char)
> (terminal-write-string string)
> (terminal-write-escape string)
>
>      write-char and write-string are like those R7RS procedures, but
>      make sure you don't accidentally write ASCII control characters
>      (other than #\newline) as those may garble the terminal.
>
>      write-escape writes the #x1B escape character followed by the
>      escape string you gave. Since escape strings don't need to feature
>      control characters either, we can use terminal-write-string
>      internally to write them.

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?

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.

> terminal-read-event [esc-timeout]
>
>      Read the next "event" from the terminal, blocking as long as
>      needed to get one.
>
>      Event types:
>
>      'control <char> where <char> is one of the graphic representations
>               of an ASCII control char: @ A B C ... X Y Z [ \ ] ^ _
>
>      'escape  <string> where <string> is the stuff after #x1B.
>               there are fairly clear rules for where to cut out the
>               part after the #x1B so the library can return one and
>               only one complete escape code to the caller.
>
>      'resize  the terminal was resized (SIGWINCH occurred), call
>               (terminal-get-size) to find out its size.
>
>      'char    <char> where <char> is a Unicode codepoint.
>
>      There is no standard way to handle the Esc key. In general, any
>      keypress Meta+X (on PC keyboards, Alt+X) is indistinguishable from
>      pressing Esc, releasing it, and then separately pressing X. Both
>      normally send the ASCII escape character (#x1B IIRC) followed by
>      the character X. (There used to be a hack where pressing Meta/Alt
>      set the high bit or "meta bit" in an ASCII character so you could
>      disginguish Meta+X from Esc X but the high bit messes with Unicode
>      whose encodings also need to use the high bit.)
>
>      Different ways to treat Esc:
>
>      * Vi-like. Esc is always a standalone Esc, never Meta+something.
>
>      * Emacs-like. Esc is always Meta+something, never standalone. When
>        we get an Esc, wait as long as needed to get the something key.
>
>      * Hybrid. When we get an Esc, wait N milliseconds for another key.
>        If another key X comes, assume Meta+X was pressed. If not,
>        assume a standalone Esc was pressed.
>
>      These can be covered by giving an `esc-timeout` argument to
>      read-event:
>
>      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.

> SIGWINCH handler
>
>      For a nice experience, terminal apps need to respond to resize.
>      For that, we need a SIGWINCH Unix signal handler. As said many
>      times on these lists, Signal handlers are notoriously unfun and
>      liable to mess with anything they touch. It might be best to
>      provide a (terminal-announce-resize) procedure that a
>      user-installed signal handler can call to tell the terminal
>      library to pass the `read-event` caller a resize event.
>
>      Otherwise we need some kind of portable way to install a SIGWINCH
>      handler, which may be difficult.

Yeah, while I haven't dealt with them since 1994, signal handling is
no fun at all.  But needed ... John et. al., is signal handling needed
for any other future SRFIs/R7RS-large you envision?  Your GitHub repo
https://github.com/johnwcowan/r7rs-work doesn't have any file with the
string signal in it.  PosixLua.md, what Lua provides in it's POSIX API
has the following:

posix-signal: kill (pid, opt)
posix-signal: killpg (pgrp[, sig=`SIGTERM`])
posix-signal: raise (sig)
posix-signal: signal (signum[, handler=SIG_DFL[, flags]])

PosixLinks.md has this Chicken 5 egg:

https://wiki.call-cc.org/man/5/Module%20(chicken%20process%20signal)

If another SRFI needs signal handling, or a general POSIX signal
handling SRFI is a good idea, facilities to supply the above desired
SIGWINCH handler should be in it.  Even if we don't envision any of
this today, we should still almost certainly put this in another SRFI
because of how much of a burden it would otherwise add to an
implementor of SRFI 205, or an "ANSI terminal fundamentals" SRFI.

- Harold