>> I would be interested in something at the level of the minsi library I
>> wrote: "just give me a raw terminal and let me read and write ANSI
>> sequences". If SRFI 205 wants to be more fine-grained, that is fine.
>
> Up to now it wants to be lower level.  And provides with-raw-mode to
> give you that raw terminal as safely as possible, i.e. less likely for
> a program exit to leave the terminal in raw mode.

Makes sense.

minsi is also about safety, but at another level: that of control
sequences and character encoding.

If we think of a terminal as a stream where we read and write stuff,
then SRFI 205 in its current form is about tweaking the out-of-band
settings of that stream, leaving the in-band part entirely to the user.

mintty also takes control of the in-band stuff such that it delimits the
input and output streams into characters and escape sequences, making
sure you read full sequences as intended, and don't accidentally write
sequences when you meant to write plain text.

With these two levels covered, we've taken care of the most common ways
to accidentally wedge the user's terminal or display junk. Though this
still leaves open the possibility of using unsupported control codes,
misjudging how much text fits on one line, etc.

A fully buffered character cell abstraction would take care of the rest.

Line editors (e.g. in Scheme REPLs) are an uncanny hybrid between
full-screen and line-oriented application. Originally they are very much
line-oriented, but supporting multi-line editing starts to involve the
control codes that are more associated with full-screen applications. In
recent years, more line editors are aspiring to be more full-screen,
adding interactive browsers for tab completion listings, on-line help
and such.

> ANSI sequences strike me at first glance as not being in its remit.

May be a wise call.

> Putting on my implementor hat, adding them should not significantly
> increase the workload after the first sample implementation, it would
> all be standard Scheme code, right?

Yes, with one important caveat - the minsi abstraction doesn't let the
user write anything raw to the terminal. minsiWriteEscape() is the
lowest-level thing, and it writes an ASCII ESC byte followed by a string
that is not allowed to include ASCII control characters.

> I'd like to know where John etc. think this level of ANSI terminal
> stuff should go.

Me too.

> A separate SRFI would be cleaner, I think, and could be a building
> block for more serious terminal user interfaces
I can make a pre-SRFI for one. We can delete it if it sucks.