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

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Cc: Eric Hanchrow <eric.hanchrow@gmail.com>,  22154@debbugs.gnu.org
> Gcc: nnml+archive:sent-mail-2015
> Date: Mon, 14 Dec 2015 01:21:26 -0500
> 
> Using different number of colors on different ttys should work.
> I just tried it briefly, and it works fine on my Fedora machine with
> 24.5.
> I don't have a very recent version compiled.
> 
> You can try it with
> $ emacs -Q -f server-start&
> Then from an xterm: emacsclient -t
> And then from a different one: env TERM=vt100 emacsclient -t
> 
> The frame in the first xterm should display some colors, the one in the
> second should be b&w...

This simple use case indeed (almost) works.  (To have it work better,
you need the patch I posted here.)  But in general, the current
implementation doesn't support this, AFAICT, for 2 reasons:

  . The default escape sequences sent to the terminal for turning
    colors on and off are stored in a single global set of values (the
    default_* variables in term.c).  So every time set_tty_color_mode
    is called, and the frame's parameters don't include the
    tty-color-mode parameter (which is what happens usually) the
    escape sequences get overwritten by the ones of the last tty we
    initialized.  It so happens that the display calls
    set_tty_color_mode each time you switch to a different frame on a
    TTY, so the risk of this happening is quite high, especially if
    some frames do have the tty-color-mode parameter.  The patch I
    sent solves this part.

  . The value of tty-defined-color-alist is global, so every call to a
    terminal-specific FOO-register-default-colors will modify that
    global value with its own colors, and those of the previous tty
    will be lost.  For example, the initialization of xterm-256 fills
    tty-defined-color-alist with colors whose names are "color-0",
    "color-1", etc., but if you later initialize an 8-color xterm,
    these get nuked, and only the 8 or 16 standard colors remain
    there.

The second part problem could only be fixed by making
tty-defined-color-alist a terminal-local variable.

Am I missing something?