# Device Component Select Mode (DCSM)

> Whether editing functions act on the presentation or the data.

- **Sequence:** `CSI 9 h`
- **ECMA-48:** [§7.2.3 DCSM – Device Component Select Mode, p. 22](https://archive.org/details/ecma-48-5th-edition-june-1991/page/n35/mode/1up)

Mode 9 is the other mode the fifth edition of ECMA-48 added for
bidirectional text. A device that reorders text for display has two
positions, one in the text as presented and one in the data as stored, and
this mode says which one functions such as [CR](https://control-codes.page/c0/cr/index.html.md), [ICH](https://control-codes.page/csi/ich/index.html.md)
and [EL](https://control-codes.page/csi/el/index.html.md) move or act on.

| State | ECMA-48 calls it | Meaning |
| --- | --- | --- |
| Reset, `CSI 9 l` | PRESENTATION | they act on the presentation component |
| Set, `CSI 9 h` | DATA | they act on the data component |

Neither xterm nor libghostty-vt implements it. Both ignore `CSI 9 h` and
`CSI 9 l`, and both answer [DECRQM](https://control-codes.page/csi/decrqm/index.html.md) with `0`, not
recognized: the mode is not among the ones xterm's [`do_ansi_rqm`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/misc.c#L5408-L5463) answers for.

## Validation

### DCSM-1: Not recognized

Input, one step per line:

```text
\e[9$p
```

Expected screen:

```text
|_____|
reply \e[9;0$y
```

### DCSM-2: Not recognized after it is set, either

Input, one step per line:

```text
\e[9h
\e[9$p
```

Expected screen:

```text
|_____|
reply \e[9;0$y
```

---

This is the Markdown version of <https://control-codes.page/ansi/dcsm/>. 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 <https://control-codes.page/notation/index.html.md>.