Struct TearCaps 

pub struct TearCaps;

What tear advertises about itself when it is the HostRole::Host.

These constants are a PROMISE, not a copy

A DA reply is a capability advertisement: a program reads it and then uses what it claims. So each field here has to be true of tear’s own renderer, and the temptation to paste mado’s constants is a trap.

mado advertises \x1b[?62;4;22c. The 4 means sixel, and mado’s own comment notes it was added “since the decode path landed”. tear has no sixel: GridState implements no hook/put/unhook, so a DCS image payload is swallowed by vte’s default no-op. Advertising 4 would tell every program on the system to send image data tear cannot draw.

So tear advertises VT220 + ANSI colour and nothing it cannot honour. When graphics land in PaneGrid, this constant moves in the same commit — that coupling is the point of it living beside the role.

Implementations

impl TearCaps

pub const PRIMARY_DA: &'static [u8] = b"\x1b[?62;22c"

Primary DA (CSI c): VT220 (62) with ANSI colour (22).

Deliberately WITHOUT 4 (sixel) — see the type doc.

pub const SECONDARY_DA: &'static [u8] = b"\x1b[>1;0;0c"

Secondary DA (CSI > c): terminal id 1, version 0, cartridge 0 — the same shape mado reports.

pub const STATUS_OK: &'static [u8] = b"\x1b[0n"

Device status report, “terminal OK” (CSI 5n).