CAN Cancel

CAN abandons whatever sequence is in progress. ECMA-48 says only that it marks the data before it as “in error”, to be ignored, and leaves the details to each application. DEC STD 070 makes them precise: CAN “causes immediate termination, without execution, of any sequence in progress”, and the characters after it “are interpreted normally”. The VT510 manual (§4.3.5) adds device control strings to what it cancels, and says that “the VT510 does not display any error character”.

Outside a sequence, CAN does nothing at all. Nothing is displayed, and the cursor does not move.

xterm handles it in CASE_CAN: it resets the parser, and only when emulating a VT100 does it also display a checkerboard error character. SUB is the same, except that it displays the error character.

Validation

CAN-1: Abandons a control sequence

A
\e[3      # CUF, unfinished
\x18      # CAN
C         # printed, not taken as the final byte

|AC___|
cursor 1,3

CAN-2: Nothing on its own

AB
\x18
C

|ABC__|
cursor 1,4

CAN-3: Abandons an escape sequence

A
\e#       # DECALN, unfinished
\x18
8

|A8___|
|_____|

CAN-4: Abandons an operating system command

\e]2;abc  # set the title, unfinished
\x18
def

|def__|
title ""

CAN-5: Abandons a device control string

\eP$qm    # DECRQSS: ask for the current SGR, unfinished
\x18

|_____|
reply none

The device control string here is DECRQSS, which asks the terminal to report a setting and needs a string terminator to finish. libghostty-vt answers it anyway, \eP1$r0m\e\\. Its parser carries out the device control string on leaving it whatever byte caused the exit (dcs_unhook in Parser.zig), so CAN finishes the string instead of cancelling it. It does tell the two apart for an operating system command, which CAN-4 shows being dropped. The VT510 manual says CAN cancels “a device control string in progress”, and DEC STD 070 that it ends any sequence “without execution”.