scrollbackLimit is documented as lines but interpreted as bytes by WASM

[darrinm]

Description

The scrollbackLimit config option is documented and typed as a line count, but the WASM terminal internally interprets it as a byte count. This mismatch means the actual scrollback capacity is drastically smaller than expected.

Details

JS side (lib/types.ts):

export interface TerminalConfig {
  scrollback_limit: number; // Number of scrollback lines (default: 10,000)
  // ...
}

And in lib/ghostty.ts:

// scrollback_limit (u32)
view.setUint32(offset, config.scrollbackLimit ?? 10000, true);

The GhosttyTerminalConfig.scrollbackLimit field and Terminal constructor's scrollback option both treat this as a line count. The default is 10000, suggesting 10,000 lines of scrollback.

WASM side: Terminal.init() / Screen.init() interprets max_scrollback as bytes. 10,000 bytes is only enough for a handful of rows depending on column width and cell size, not 10,000 lines.

Impact

• Users setting scrollback: 10000 (the default) get far less scrollback than expected
• The small buffer causes pages to wrap frequently, which can trigger viewport corruption when the viewport spans multiple pages (see getViewport() returns corrupted data when viewport spans multiple pages #139)
• Workaround: pass a very large value (e.g., 5_000_000) to approximate a reasonable scrollback depth

Expected behavior

Either:

1. The JS layer should convert line counts to bytes before passing to WASM (e.g., lines * cols * CELL_SIZE), or
2. The documentation and type comments should clearly state the unit is bytes, and the default should be adjusted accordingly (native Ghostty uses 10MB)

Related

• getViewport() returns corrupted data when viewport spans multiple pages #139 — viewport corruption is exacerbated by the undersized scrollback buffer
• fix: use cached row pins for WASM viewport rendering #133 — draft PR that includes a comment fix noting this discrepancy