Emacs xterm specific initialization does not complete properly
See original GitHub issueThe 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
- Run the
emacs
command - Observe the current window
*scratch*
is opened. Expected that the*GNU Emacs*
window is opened.
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Terminal emacs colors only work with TERM=xterm-256color
On my machine, the terminal-specific initialization files are in /usr/local/share/emacs/25.*/lisp/term . It has files for xterm, rxvt, ...
Read more >terminal emacs - "End" key results in "<select> is undefined" after ...
The End key does not work properly and results in a <select> is undefined message displaying. Any experience of this? I tested it...
Read more >Running Shells and Terminal Emulators in Emacs
Emacs's emulator isn't complete or perfect, so some interactive programs won't work properly, but most things like top or even vi will. To...
Read more >239344 – emacs crashes on startup - Red Hat Bugzilla
emacs tries to work around some implementation details. Specifically, when dumping no mmap-ed pages must be present. The program calls mallopt() in an...
Read more >XTerm – Frequently Asked Questions (FAQ) - Thomas E. Dickey
That is, xterm (pronounced "eks-term") is a specific program, not a ... Even for cases where they implement a function, it may not...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This is prolly caused by the returned sequence from here: https://github.com/xtermjs/xterm.js/blob/7ff27240f09f23f6df033aa9485dd04e2eba481d/src/browser/Terminal.ts#L227
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).
Thanks, @meganrogge, and @jerch! I’ve checked your change. It solves the issue. 🎉
I cannot wait for the 4.19.0 release.🥇 😄