Per Bothner

> Seems like the fundamental ideas can remain, just with _test transformed into a typed array managed by us where each character can take up multiple bytes. One possibility is...

If we remove the `_text` string field and include codepoints in the `_data` array then the `DataKind` bits could be: ``` const enum DataKind { // 4 bits FG =...

> wouldn't including the text data in _data complicate changing text and attributes in the middle much more complicated as it's much more likely to need to shift data around?...

An idea that seems to make sense for at least the transition period and perhaps permanently: Instead of extensively changing the API, we still use the "column number" as the...

I've started re-vamping the BufferLine re-implementation based on these comments. I just checked in the first batch of changes. * We now store character values in the `_data` array. I...

Update and status of my fork: Both the old `BufferLine` implementation (renamed to `OldBufferLine`) and the new the implementation (renamed to `NewBufferLine`) are available in the source. Instead of `new...

It might make sense to update the the proposal to match the current implementation. On the other hand, it might be helpful to get some feedback that the current approach...

I did a merge from upstream/master. `git diff master` appears to show something sane ....

I did just notice there is still some old crud in CellData: `_stateA` and related fields that are no longer used. I'll clean that up.

I committed a cleanup of `Celldata.ts`.