I assume you meant `tty-color-mode-alist'. After running `emacs -Q' with TERM set to `xterm-256color`, I see tty-color-mode-alist is a variable defined in ‘tty-colors.el’. Its value is ((never . -1) (no . -1) (default . 0) (auto . 0) (ansi8 . 8) (always . 8) (yes . 8)) After the client frame is created, it's the same. `terminal-init-xterm` does indeed run when I create the client frame, but as you can see, it doesn't modify tty-color-mode-alist. On Sun, Dec 13, 2015 at 10:37 AM Eli Zaretskii wrote: > > Date: Sun, 13 Dec 2015 20:17:11 +0200 > > From: Eli Zaretskii > > Cc: 22154@debbugs.gnu.org > > > > > From: Eric Hanchrow > > > Date: Sun, 13 Dec 2015 10:05:20 -0800 > > > Cc: 22154@debbugs.gnu.org > > > > > > Does the patch below fix the problem? > > > > > > It doesn't seem to make any difference. > > > > Strange, it did make a difference on my system. > > > > I guess I will then have to ask you to step in a debugger through > > set_tty_color_mode and tty_setup_colors, and tell what is stored in > > the default_* members of the tty object during the main Emacs > > initialization and when the client frame is created. I have no access > > to a system with a 256-color xterm. > > It could also be tty-color-alist. Can you tell me what's in it after > Emacs starts on a 256-color xterm, and after the client frame is > created? Also, does xterm.el initialization get called for the client > frame, and does it modify tty-color-alist? > >