# 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.
## Support
| Terminal | Version | Support | Notes |
| --- | --- | --- | --- |
| VT220 | [manual](https://vt100.net/docs/vt220-rm/), 2nd ed., 1984 | Yes | [§4.2 Control Characters](https://vt100.net/docs/vt220-rm/chapter4.html#S4.2) |
| VT510 | [manual](https://vt100.net/docs/vt510-rm/), 1st ed., 1993 | Yes | [Table 4–1](https://vt100.net/docs/vt510-rm/chapter4.html#T4-1) |
| xterm | patch 412, [xterm-411a](https://github.com/ThomasDickey/xterm-snapshots/tree/xterm-411a) | Yes | shows an error character only when emulating a VT100 |
| libghostty-vt | [0f171f6](https://github.com/ghostty-org/ghostty/tree/0f171f650a1cbbd6df4a2573b6b0c7de57cc6d90) | Yes | CAN-5: finishes a device control string instead of cancelling it |
| kitty | 0.49.1, [run in a VM](https://git.jcollie.dev/jeff/control-codes/src/branch/main/emulators/results/kitty.json) | Yes | passes the 2 cases that show it working |
| foot | 1.28.0, [run in a VM](https://git.jcollie.dev/jeff/control-codes/src/branch/main/emulators/results/foot.json) | Partly | fails CAN-4 of the 3 cases that show it working |
| pyte | 0.8.2, [run as a library](https://git.jcollie.dev/jeff/control-codes/src/branch/main/emulators/results/pyte.json) | Partly | fails CAN-4 of the 3 cases that show it working |
| xterm.js headless | 6.0.0, [run as a library](https://git.jcollie.dev/jeff/control-codes/src/branch/main/emulators/results/xtermjs.json) | Yes | passes the 3 cases that show it working |
| alacritty_terminal | 0.26.0, [run as a library](https://git.jcollie.dev/jeff/control-codes/src/branch/main/emulators/results/alacritty.json) | Partly | fails CAN-4 of the 3 cases that show it working |
| rxvt-unicode | 9.31, [run in a VM](https://git.jcollie.dev/jeff/control-codes/src/branch/main/emulators/results/urxvt.json) | Partly | fails CAN-1 of the 3 cases that show it working |
| VTE | 0.84.1, [run as a library](https://git.jcollie.dev/jeff/control-codes/src/branch/main/emulators/results/vte.json) | Yes | passes the 3 cases that show it working |
## 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 .