Start Of String control sequence behaviour following DEC rather than ECMA-48?

[EnronEvolved]

ECMA-48, section 8.3.128, defines the behaviour of the ESC-X SOS (Start Of String) control sequence, stating (emphasis mine)

The character string following may consist of any bit combination, except those representing SOS or STRING TERMINATOR (ST). The control string is closed by the terminating delimiter STRING TERMINATOR (ST).

(See also section 5.6 on control strings)

Ghostty does not comply with this definition, though, admittedly, few terminal emulators do. Running print("\x1bXfoo\x1bebar\x1b\\") in Python (ESC-X foo ESC-e bar ESC-\), under Ghostty 1.0.1-main+a8e5eef1, indicates that the escape sequence is terminated by any escape, according to DEC behaviour.

A discussion of this divergence of behaviour in relation to Alacritty can be found here.

[rockorager]

Interesting bug. I guess this comes down to what is Ghostty emulating. The ever popular Paul Flo Williams parser states (emphasis mine)

A control string that started with DCS, OSC, PM or APC is usually terminated by the C1 control ST (String Terminator). In a 7-bit environment, ST will be represented by ESC \ (1B 5C). However, receiving the ESC character will “cancel” the control string, so the ST control function that is invoked by the arrival of the following “\” is essentially a “no-op” function. Does this point seem like pure trivia? Maybe, but I worried for ages about whether the control string recogniser needed a one character lookahead in order to know whether ESC \ was going to terminate it. The actual solution became clear when I was using ReGIS on a VT330: sending ESC immediately caused the graphics output cursor to disappear from the screen, so I knew that the control string had already finished before the “\” arrived.

No mention of SOS here.

In this comment, j4james quotes the DEC standard:

For backward compatibility, and to minimize the effect of a lost String Terminator, the control codes CAN (1/8), SUB (1/10), ESC (1/11), or any C1 control will also terminate control strings.

This is in reference to a section called Device Control Strings, which lists the following supported openers:

• DCS
• APC
• OSC
• PM

Again, no mention of SOS yet. In the very next section they state:

The use of SOS and character strings within Digital is reserved for future standardization. Note that ISO may define the inclusion of escape and control sequences inside Character Strings

So - DEC doesn't support it. If we are emulating DEC it's not clear what we should do. I think from a strict reading of ECMA, we are behaving incorrectly (as are most other terminals).

@mitchellh - What do you think? I think the correct thing to do is to special case \x1BX strings to swallow until ST

[rockorager]

DEC also states, regarding unimplemented control strings (SOS in this case)

The contents of received control strings that are not implemented by the receiving party will be ignored. Therefore, all data (control and graphic characters) from the control string introducer to the string terminator (inclusive) will be discarded without being displayed