# Format Effector Transfer Mode (FETM)

> Whether formatting functions may be added to what is transmitted.

- **Sequence:** `CSI 14 h/l`
- **ECMA-48:** [§7.2.6 FETM – Format Effector Transfer Mode, p. 22](https://archive.org/details/ecma-48-5th-edition-june-1991/page/n35/mode/1up)
- **DEC STD 070:** [§5.10.1.3 Modes That Cannot Be Changed, p. 5-134](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n388/mode/1up)

Mode 14 decides whether the terminal may add formatting functions of its
own to what it transmits, or only passes on the ones it stored under
[FEAM](https://control-codes.page/ansi/feam/index.html.md).

| State | ECMA-48 calls it | Meaning |
| --- | --- | --- |
| Reset, `CSI 14 l` | INSERT | formatting functions may be inserted |
| Set, `CSI 14 h` | EXCLUDE | only those stored under FEAM are sent |

[DEC STD 070 §5.10.1.3, p. 5-134](https://archive.org/details/bitsavers_decstandar0VideoSystemsReferenceManualDec91_74264381/page/n388/mode/1up) lists it among the X3.64 modes a DEC terminal may treat as fixed,
as not applicable. The VT510 manual's [table of modes for DECRPM](https://vt100.net/docs/vt510-rm/DECRPM.html) marks it as always reset.

xterm ignores `CSI 14 h` and `CSI 14 l` ([`ansi_modes`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/charproc.c#L7399-L7424) handles only modes 2,
4, 12 and 20), and [DECRQM](https://control-codes.page/csi/decrqm/index.html.md) reports the mode as permanently
reset, `4` ([`do_ansi_rqm`](https://github.com/ThomasDickey/xterm-snapshots/blob/xterm-411a/misc.c#L5408-L5463)). libghostty-vt ignores it too, but does not recognize the
number, so it answers DECRQM with `0`. Both DECRQM cases are known
differences.

## Support

| Terminal | Version | Support | Notes |
| --- | --- | --- | --- |
| VT220 | [manual](https://vt100.net/docs/vt220-rm/), 2nd ed., 1984 | No | not in the manual, whose table of ANSI modes has only KAM, IRM, SRM and LNM |
| VT510 | [manual](https://vt100.net/docs/vt510-rm/), 1st ed., 1993 | No | [listed as permanently reset](https://vt100.net/docs/vt510-rm/DECRPM.html) |
| xterm | patch 412, [xterm-411a](https://github.com/ThomasDickey/xterm-snapshots/tree/xterm-411a) | No | ignored; DECRQM reports it permanently reset, `4` |
| libghostty-vt | [0f171f6](https://github.com/ghostty-org/ghostty/tree/0f171f650a1cbbd6df4a2573b6b0c7de57cc6d90) | No | ignored; DECRQM answers `0` (FETM-1, FETM-2) |
| ConEmu | build 230724, its [documentation](https://conemu.github.io/en/AnsiEscapeCodes.html) | No | not in its [ANSI escape codes](https://conemu.github.io/en/AnsiEscapeCodes.html) |

## Validation

### FETM-1: Reported as permanently reset

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

```text
\e[14$p
```

Expected screen:

```text
|_____|
reply \e[14;4$y
```

### FETM-2: Even after it is set

*A known difference: libghostty-vt does not pass this case.*

Input, one step per line:

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

Expected screen:

```text
|_____|
reply \e[14;4$y
```

---

This is the Markdown version of <https://control-codes.page/ansi/fetm/>. 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>.