HVP — Horizontal and vertical position (CSI f, alias of CUP)

Used in

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

• DEC VT510 RM applications (historical)—DEC's VT510 Reference Manual presents HVP as the canonical positioning sequence — pre-1990 VAX / VMS apps written against the VT100-family manuals emit `\x1b[<r>;<c>f` everywhere even though they could have used CUP. Reading these legacy listings is the main place modern engineers encounter HVP
• WordPerfect for DOS cursor positioning—WordPerfect 5.x emitted HVP for cell positioning on DEC and IBM-3151 terminals — the product's Windows port dropped HVP support but DOS executables still in archival use produce the byte sequence when shelled out from DOSBox over a real serial line
• ncurses fallback when `cup` cap is missing—if a terminfo entry lacks the `cup` (cursor address) capability but defines `hpa` + `vpa`, ncurses falls back to HVP-style composed addressing — rare in practice (every modern entry has `cup`), but `tic` / `infocmp` will compile a `cup=\E[%i%p1%d;%p2%df` cap if the entry author wrote it
• mosh state-replay engine—mosh's terminal-state diff replay treats CUP and HVP as fully equivalent during the SSP frame-rebuild pass — its parser maps `H` and `f` final bytes to the same `move_cursor(row, col)` state mutation, so a legacy stream emitting HVP replays correctly across reconnects
• `tic` / `infocmp` terminfo round-trip—round-tripping an old `vt100` or `vt220` terminfo through `infocmp -L` → `tic` will preserve the `cup=\E[%i%p1%d;%p2%df` HVP-form if it was authored that way — useful when porting a 1990s mainframe terminfo entry to a modern Linux box and you want to keep the byte-for-byte identical sequence stream

Related pitfalls

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

• ⚠\x1b[0;0f (HVP, Pn1=Pn2=0) does not land at the top-left — HVP is identical to CUP, top-left is \x1b[1;1f·#cup-1-based-not-0-based
• ⚠\x1b[f (omitted Pns) defaults to 1;1, not 0;0 — same rule as CUP \x1b[H·#csi-default-params

Frequently asked

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

Is \x1b[<r>;<c>f (HVP) the same as \x1b[<r>;<c>H (CUP)?

Effectively yes on every terminal in the support matrix. ECMA-48 specifies HVP as having identical positioning semantics to CUP — both are 1-based, both default Pn1/Pn2 to 1 when omitted, both move the cursor without scrolling. The historic distinction was that HVP belonged to a different ECMA category (presentation control vs editor control) and could be inhibited independently by SCS — irrelevant on modern terminals. The de-facto convention is to emit CUP \x1b[H since it's the byte everyone implements first; reserve \x1b[f for code that already used it.

When should I use HVP \x1b[f instead of CUP \x1b[H?

Almost never — pick CUP \x1b[H for new code. The only practical reason to emit HVP is reading legacy code or working with a parser that the source already wrote against f. ECMA-48 keeps both around for spec compliance, but every emulator in the support matrix treats them identically. If you're emitting through a stack that strips one of them (rare — typically only DEC VT510 RM-strict parsers), the other still gets through; otherwise the choice is purely stylistic.