The Screen Model

Between "bytes arrive" and "pixels change" every terminal keeps an in-memory model of the display. So does every full-screen program talking to a terminal — vim doesn't re-send your whole file on each keystroke; it maintains what the screen should look like and sends the difference. Both directions of this course now converge on the same data structure: a grid of cells.

Why not just write() as you go?

Because of what you'd be writing to. Three separate costs punish scattered small writes:

1. Syscalls aren't free. A write() is a user→kernel→user round trip — over a thousand times the cost of a memory store. Painting a 50×200 screen cell-by-cell is 10,000 syscalls to draw one frame you could send in one.
2. Flicker. The terminal renders whenever it likes — including after your "clear screen" but before your "draw contents". The user sees a blank flash. Batch the clear and the redraw into one write and there is no in-between state to glimpse.
3. Tearing over distance. Over ssh, each write can become a packet. Half a frame per packet means the user literally watches your UI assemble.

So the architecture — the same one in kilo, vim, and ncurses — is:

mutate cells in memory  →  serialize to ONE byte buffer  →  ONE write()

Nothing touches the fd until the frame is complete.

The cell

A terminal cell is a glyph plus its styling — the "brush" that was active when it was painted:

struct cell {
    char ch;              /* the glyph                              */
    unsigned char fg;     /* 0-7 = basic colors, 9 = default        */
    unsigned char bg;     /*                 same                   */
    unsigned char attrs;  /* CELL_BOLD | CELL_UNDERLINE | CELL_REVERSE */
};

The grid is rows * cols of these. Resist the 2D-array temptation — struct cell grid[ROWS][COLS] hardcodes the size at compile time, and terminals resize at runtime. One malloc(rows * cols * sizeof(struct cell)) and the classic flattening

cell = &s->cells[row * s->cols + col];

gives you a grid of any size, reallocatable on SIGWINCH. (That row * cols + col line will appear in your dreams. It should: get it backwards — col * rows + row — and everything almost works, which is worse than not working.)

Alongside the grid, the screen keeps a cursor (where the next glyph lands) and the current brush (what style it lands with). SGR's statefulness, which looked like a wire-protocol quirk two lessons ago, turns out to be this: the brush is state in the screen model, and the wire just mutates it.

The append buffer

The serialize step needs a growable byte buffer to accumulate the frame — cells, cursor moves, SGR changes — before the single write. C won't hand you one; you'll build it (kilo calls its version abuf, dynamic-array veterans will recognize the pattern):

struct abuf {
    char  *b;    /* heap storage           */
    size_t len;  /* bytes used             */
    size_t cap;  /* bytes allocated        */
};

The one interesting decision is the growth policy. Growing to exactly the needed size makes N appends cost O(N²) total (each realloc copies everything so far). Growing geometrically — doubling — makes the total O(N): each byte is copied at most a constant number of times, amortized. This single idea is why std::vector, Go slices, and Python lists are fast; today you get to own it in nine lines.