Viewport Scrolling & Status Bar

The terminal is 24×80, but the document might be 50 000 lines × 200 cols wide. The editor shows a viewport — a rectangular window into the document. Two offsets describe it:

• row_off — index of the document row at the top of the screen.
• col_off — index of the document column at the left of the screen.

After every cursor move, you nudge the offsets so the cursor stays on-screen. The algorithm (lifted from kilo) is four lines:

void editorScroll() {
    if (cy < row_off)              row_off = cy;
    if (cy >= row_off + rows)      row_off = cy - rows + 1;
    if (cx < col_off)              col_off = cx;
    if (cx >= col_off + cols)      col_off = cx - cols + 1;
}

This is minimum-displacement scrolling: the viewport only moves as far as it has to. The cursor lands exactly at the edge (first or last visible row/col), not centered. Power users learn zz in vim (center) and H/M/L (top/middle/bottom) to override.

The status bar is the inverted-video line at the bottom of the screen. It typically shows:

• Filename + [Modified] flag if dirty
• Filetype / encoding / line endings
• Cursor position: row Y, col X or Y/total
• Mode (Normal / Insert / Visual) for modal editors

Kilo draws the status bar with \x1b[7m (inverse video on) + text + \x1b[m (reset). VS Code, Helix, Zed all have richer status bars but the role is the same: tell the user where they are.

A message bar (one line below status) shows transient hints: :w confirmations, Ctrl-S = save | Ctrl-Q = quit, search prompts. Kilo clears it after 5 seconds.

This lesson asks you to implement editorScroll and the status-bar formatter. Tiny code, huge UX impact — without scrolling, the editor is unusable beyond one screen.

Reference: kilo editorScroll + editorDrawStatusBar; Hecto chapter 7.