ConEmu Extensions (OSC 9;n)
Various extensions pioneered by ConEmu.
ConEmu, an older terminal emulator for Windows, pioneered several custom protocols using OSC 9. Unfortunately, this conflicts with iTerm2's Show Desktop Notification protocol, which also uses OSC 9. Ghostty attempts to differentiate between the two by trying to find the sub-ID that each ConEmu sequence has, which determines its actual function. When one is not found, a Show Desktop Notification sequence is assumed instead.
Because the following protocols are often underspecified at best and highly questionable security-wise at worst, Ghostty only implements the extensions that are listed below. There are many more that Ghostty does parse, but either due to security reasons or the fact that Ghostty does not try to be a ConEmu clone, they are either ignored or converted into OSC 9 sequences.
- 0x1B
- ESC
- 0x5D
- ]
- 0x39
- 9
- 0x3B
- ;
- 0x34
- 4
- 0x3B
- ;
- ____
- s
- 0x1B
- ESC
- 0x5C
- \
- 0x1B
- ESC
- 0x5D
- ]
- 0x39
- 9
- 0x3B
- ;
- 0x34
- 4
- 0x3B
- ;
- ____
- s
- 0x3B
- ;
- ____
- v
- 0x1B
- ESC
- 0x5C
- \
Change the current progress state based on the value of s and v.
The current progress can be in various states: inactive (default), in progress, error, or indeterminate, which is represented visually in Ghostty as a progress bar on top of each split. Its value is represented as an integer between 0 and 100 inclusive, corresponding to the percentage level of the progress bar.
The new state and value chiefly depends on the value of s:
s | New state | New value |
|---|---|---|
0 | Inactive | 0 |
1 | In progress | v |
2 | Error | v when specified, otherwise unchanged |
3 | Indeterminate | Unchanged |
4 | Paused | v when specified, otherwise unchanged |
Note
Note that the terminal cannot determine when a progress state becomes stale with this protocol, e.g. when a program is terminated without cleaning up its progress state. This is why Ghostty has a hardcoded timeout of around 15 seconds, after which the current progress state is reset.
If you're writing a program that uses this protocol, you need to make sure to update the progress state regularly as a keep-alive signal. There is sadly no standardization around this, but we recommend at least updating once per second.