# Cancel (CAN)
> Abandon the escape sequence, control sequence or control string in progress.
- **Sequence:** `CAN`
- **ECMA-48:** [§8.3.6 CAN – Cancel, p. 34](https://archive.org/details/ecma-48-5th-edition-june-1991/page/n47/mode/1up)
- **DEC STD 070:** [§3.5.1.2.1 Cancel, p. 3-19](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n123/mode/1up)
- **VT220:** [§4.2 Control Characters](https://vt100.net/docs/vt220-rm/chapter4.html#S4.2)
- **VT510:** [4.2 Control Characters](https://vt100.net/docs/vt510-rm/chapter4.html#S4.2)
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](https://vt100.net/docs/vt510-rm/chapter4.html#S4.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`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/charproc.c#L3618-L3644): it resets the
parser, and only when emulating a VT100 does it also display a checkerboard
error character. [SUB](https://control-codes.page/c0/sub/index.html.md) is the same, except that it displays the
error character.
## Validation
### CAN-1: Abandons a control sequence
Input, one step per line:
```text
A
\e[3 # CUF, unfinished
\x18 # CAN
C # printed, not taken as the final byte
```
Expected screen:
```text
|AC___|
cursor 1,3
```
### CAN-2: Nothing on its own
Input, one step per line:
```text
AB
\x18
C
```
Expected screen:
```text
|ABC__|
cursor 1,4
```
### CAN-3: Abandons an escape sequence
Input, one step per line:
```text
A
\e# # DECALN, unfinished
\x18
8
```
Expected screen:
```text
|A8___|
|_____|
```
### CAN-4: Abandons an operating system command
Input, one step per line:
```text
\e]2;abc # set the title, unfinished
\x18
def
```
Expected screen:
```text
|def__|
title ""
```
### CAN-5: Abandons a device control string
*A known difference: libghostty-vt does not pass this case.*
Input, one step per line:
```text
\eP$qm # DECRQSS: ask for the current SGR, unfinished
\x18
```
Expected screen:
```text
|_____|
reply none
```
The device control string here is
[DECRQSS](https://vt100.net/docs/vt510-rm/DECRQSS.html), 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".
---
This is the Markdown version of . On that page every validation case runs live in libghostty-vt, the terminal emulation core of Ghostty, compiled to WebAssembly.
The validation cases are written in the notation described in .