So far I've been assuming that read-key only works for ascii, and that
I'd need to get more sophisticated both for multi-byte utf-8 and multi-byte
terminal escape codes like arrow keys. Rather to my surprise, both work
fine. We just need to adjust the types to reflect this fact.
tile is already visibly slow (49x212 screen) :/ So programmer needs more
control over performance.
But this may not be the right approach. That extra flush-stdout in tui.mu
suggests it's either going to be finicky, or we have to flush on every
attribute change. And going through a buffered-file may be slower. May.
No support for combining characters. Graphemes are currently just utf-8
encodings of a single Unicode code-point. No support for code-points that
require more than 32 bits in utf-8.
Both have the same size: 4 bytes.
So far I've just renamed print-byte to print-grapheme, but it still behaves
the same.
I'm going to support printing code-points next, but grapheme 'clusters'
spanning multiple code-points won't be supported for some time.
We now have all existing apps and prototypes going through the dependency-injected
wrapper, even though it doesn't actually implement the fake screen yet.
Slices contain `addr`s so the same rules apply to them. They can't be stored
in structs and so on. But they may be an efficient temporary while parsing.
Streams are currently a second generic type after arrays, and gradually
strengthening the case to just bite the bullet and support first-class
generics in Mu.
Kartik Agaram