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

[Eli Zaretskii <eliz@gnu.org>]

> From: Dan Nicolaescu <dann@gnu.org>
> Cc: eric.hanchrow@gmail.com,  22154@debbugs.gnu.org
> Date: Tue, 15 Dec 2015 00:46:08 -0500
> 
> >> What exactly is the problem that your patch fixes?
> >
> > The fact that the default escape sequences for turning colors on or
> > off are stored in global variables that get overwritten each time
> > another tty is initialized.
> 
> Can you describe a behavior that is incorrect?

It was described in the original report of this bug, see

  http://lists.gnu.org/archive/html/bug-gnu-emacs/2015-12/msg00420.html
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22154#5

> > And I don't understand how could what you describe work when there's
> > only one global value of tty-defined-color-alist.  Can you explain how
> > that worked, given that each terminal's initialization overwrites that
> > list?
> 
> Sorry, I don't remember the details, but it did work
> In fact I just tried on emacs 24.5 with 3 terminals: xterm
> with TERM=vt100, rxvt -fg black -bg white and rxvt -fg white -bg black.
> emacsclient -t connected to the same emacs daemon

That's not the same use case.  The one you should indeed works,
because the foreground and background colors are recorded separately
for each frame.  IOW, this is not related to the issue at hand.

The issue at hand is how a TTY frame interprets a color specified
either by its name, like "LavenderBlush", or by an RGB value, like
#FF12EC.  As you certainly remember, we look for the best match in the
list returned by tty-color-alist, then use the numeric value of that
best match to send the corresponding escape sequence to the TTY
device.

The problem I alluded to has 2 facets:

  . the list which we need to find the best matching supported color
    is overwritten every time we initialize another tty, because that
    list is maintained as a single global variable

  . the escape sequences and the number of supported colors are also
    overwritten, because they are restored from a single static
    variable

My patch solves the 2nd part, but the first also needs to be solved.

> Unfortunately I don't have a more recent emacs version on this machine...

I don't think you need a newer Emacs, the same problem should exist in
24.5.  Just do what the OP did with an Emacs running under a 256-color
xterm and a client frame started under an 8-color xterm.  If this
works in Emacs 24.5, I'm probably missing something very important.

Eric, can you test your scenario with Emacs 24.5, please?