Emacs xterm specific initialization does not complete properly

[EvgeneOskin]

The emacs cannot define xterm configuration of the background color.
I've debugged the issue down to the point when emacs queries the xterm background color.

Unfortunately, I cannot provide more exact reasons and errors due to a lack of emacs debugging experience.

Details

• Browser and browser version: Electron 17
• OS version: macOS 12.3
• xterm.js version: 4.17.0 and 4.18. Possibly, 4.16.0 affected, too.
• emacs: 26 or 27. Most probably, older versions are affected, too

Steps to reproduce

1. Run the emacs command
2. Observe the current window
3. *scratch* is opened. Expected that the *GNU Emacs* window is opened.

[EvgeneOskin]

For the record, it looks like xtermjs handles printf "\x1b]11;?\x07" properly.

[jerch]

This is prolly caused by the returned sequence from here:

xterm.js/src/browser/Terminal.ts

Line 227 in 7ff2724

this.coreService.triggerDataEvent(`${C0.ESC}]${ident};${toRgbString(channels)}${C0.BEL}`);

which appends BEL as OSC finalizer, while the emacs function expects ST as finalizer in https://github.com/emacs-mirror/emacs/blob/d7f4cc0974645cc6a295740afe85c6e21d956119/lisp/term/xterm.el#L682.

Background: BEL as OSC finalizer was a defacto standard for several years introduced by xterm somewhere in the 90s. ST is the official and only allowed finalizer from ECMA-48. Now there is some confusion, whether to use BEL or ST. Newer xterm versions switched to ST I think, guess xterm.js should use ST as well (with a chance to break older apps though, that only scan for BEL).

[Tyriar]

I've got reports like this about emacs breaking and opening a scratch file for some time now and was totally puzzled by them microsoft/vscode#142754. If we can fix this by switching to ST here that's great news 🎉

[Tyriar]

fyi @meganrogge

[meganrogge]

Nice find! @jerch I was stumped as well.

[EvgeneOskin]

Thanks, @meganrogge, and @jerch!
I've checked your change. It solves the issue. 🎉

I cannot wait for the 4.19.0 release.🥇 😄