Core abstraction

[lassik]

What is the main abstraction this SRFI should provide?

I would vote for something like:

• the user is presented a character cell grid
• we store that grid in a memory buffer and the user can change it
• we also store another grid that contains the data last drawn to the screen
• when the user tells the library to update the screen, the library computes the difference between the last screen contents and the current grid, and draws only the changed parts in a way that tries to minimize screen flicker

The grid would be presented in a platform-independent way: characters are Scheme char objects, colors are RGB values or strings like "red" and "green", etc.

IMHO we should not deal with things like making TUIs in this SRFI. There is no agreement on how to do that, and it's not fundamental to the character cell grid abstraction. If a Scheme implementation provides a character cell grid, then it's easy to experiment with TUI libraries written fully in Scheme.

[johnwcowan]

I agree on all points except these (see Terminals.md):

1. Cells need to contain strings rather than characters, because there are a number of special cases: (a) wide characters like Chinese characters occupy two cells, so the character is stored in the left cell and "" in the right; (b) a base character can be followed by any number of combining diacritics; (c) a triplet of conjoining Hangul characters is equivalent to a wide Hangul character.

2. The foreground and background colors of a cell are 0xRRGGBB, but the terminal is free to reduce this to as few as 8 colors, or even 2 if it is a monochrome device.

[lassik]

1. Cells need to contain strings rather than characters, because there are a number of special cases: (a) wide characters like Chinese characters occupy two cells, so the character is stored in the left cell and "" in the right; (b) a base character can be followed by any number of combining diacritics; (c) a triplet of conjoining Hangul characters is equivalent to a wide Hangul character.

Excellent. I'm grateful that we have you on board to make sure non-ASCII text is done right.

It would probably make sense to have an API like (write-string-at x y "foo bar") where the implementation internally breaks down the string into however many cells are needed. Perhaps there could also be a (put-char-at x y #\c).

[lassik]

Color discussion split off into #6