bug#22154: 25.0.50; emacsclient -c "breaks" 256-color display in server

[Eric Hanchrow]

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 <eliz@gnu.org> wrote:

> Date: Sun, 13 Dec 2015 20:17:11 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22154@debbugs.gnu.org
>
> > From: Eric Hanchrow <eric.hanchrow@gmail.com>
> > 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?