DECOM ?6 — Origin mode (clip cursor addressing to scroll region)

Used in

Real-world tools that emit this sequence — anchors the bytes to commands you've already used.

• vim / neovim window splits + `:set scrollbind`—Vim splits set per-window DECSTBM scroll regions; with `scrollbind` enabled, the sync logic uses `\x1b[?6h` for the duration of cross-window cursor moves so coordinates are window-local — disable via `:set noscrollbind` and the DECOM emit disappears (`:set verbosefile=/tmp/v.log verbose=15`)
• neovim floating-window scroll regions—Floating windows created with `nvim_open_win()` each get a private DECSTBM region; when content scrolls in a float, neovim emits `\x1b[<top>;<bot>r\x1b[?6h<draw>\x1b[?6l\x1b[r` to scope coords — visible by setting `relativenumber` on a float and tracing with `--log-level=trace`
• tmux pane scroll-region setup—tmux uses per-pane DECSTBM regions; for status-line panes (`set -g status-position bottom`) the body region is `\x1b[1;<rows-1>r` and DECOM `\x1b[?6h` lets the inner app treat its top-left as `\x1b[1;1H` — tmux ≥ 3.2 negotiates DECOM through to the pane via `allow-passthrough on`
• ncurses `setscrreg()` + `wsetscrreg()`—Curses calls that set per-window scroll regions translate to terminfo `csr` (`\x1b[<top>;<bot>r`); some implementations also flip DECOM via the `om` boolean capability when the application requests window-relative coordinates — `infocmp -1 xterm | grep -E 'csr|om'`
• less status line preservation via `?6h`+CUP composite—`less ≥ 600` with `-N` (line numbers) keeps a fixed status row at top; the redraw cycle on `j`/`k` emits `\x1b[<top>;<bot>r\x1b[?6h\x1b[<rel>;1H<content>\x1b[?6l` so per-frame CUP coords stay relative to the body region — observable via `script -c 'less -N file' /tmp/log && strings /tmp/log | grep -E '\?6h|\[r'`

Related pitfalls

Known footguns this sequence creates in the wild. Each links to the full symptom + cause + fix.

• ⚠DECOM ?6h rebases CUP / HVP / CHA / VPA coordinates to be relative to top-of-region (set by DECSTBM) — \x1b[1;1H after \x1b[2;23r\x1b[?6h lands at row 2 col 1, NOT row 1; apps written assuming absolute coords silently land mid-region·#cup-1-based-not-0-based
• ⚠DECSTBM \x1b[r reset to full-screen does NOT clear DECOM — ?6h persists across region change, symptom hides until next region set; defensive idiom emit \x1b[?6l\x1b[r together, or use DECSTR \x1b[!p which resets both atomically·#decstbm-persistent-no-reset

Frequently asked

Short answers to the questions developers actually search for this sequence.

When should I use DECOM \x1b[?6h (origin mode)?

Only inside applications that set a DECSTBM scroll region AND want all subsequent cursor-positioning sequences to be relative to the region's top-left instead of the screen's. The classic use case is a fixed status line: set the region to rows 2–24 with \x1b[2;24r, enable \x1b[?6h, and now \x1b[1;1H lands at row 2 (top of region) without your code having to know the status-line offset. Most modern TUI authors avoid ?6h entirely and just bias coordinates in application code — it's one less stateful mode to track across signal handlers and crash paths. If you do use it, pair set/reset with the region's lifecycle and emit \x1b[?6l\x1b[r together when returning to defaults, since DECSTBM reset does NOT clear DECOM.

Why does \x1b[1;1H land at row R+1 instead of row 1 after I set a scroll region?

DECOM ?6h is active. Origin mode rebases all subsequent CUP / HVP / CHA / VPA coordinates to be relative to the top of the current DECSTBM scroll region — so \x1b[1;1H after \x1b[<top>;<bot>r\x1b[?6h lands at row <top>, column 1, NOT row 1, column 1. Two fixes: (a) explicitly disable origin mode with \x1b[?6l before the move if you need absolute coords, or (b) compute the absolute target as <top> + relative_row - 1. Note that \x1b[r (reset region to full-screen) does NOT clear ?6h on any modern terminal — DECOM persists across DECSTBM reset, and the symptom hides until you set a new region.