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

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

[Eric Hanchrow]

[-- Attachment #1: Type: text/plain, Size: 3541 bytes --]

I have TERM set to 'xterm-256color'.

I started emacs with `/mnt/emacs-25/src/emacs -Q`

I confirmed that 256 colors "worked" by doing M-x list-colors-display
RET, and noting that there were about 256 lines of output, with plenty
of different colors.

I typed M-x server-start RET.

In another terminal on the same machine, I typed `TERM=xterm
/mnt/emacs-25/lib-src/emacsclient -c`.  That displayed a *scratch*
buffer, as I'd expected.

In that new frame, I typed `M-x list-colors-display RET`.  I noticed
that now there were only eight lines of output.

I did C-x 5 0 to delete the new frame, then back in the original frame
again typed `M-x list-colors-display RET`, and noted that there were
still only eight lines of output.

I don't directly care about the number of output lines from the
list-colors-display command, but I do directly care that, for example,
the face "brightyellow" looks different from the default; that's the
case when 256 colors are "working", but not when they're not.  It was



In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu)
 of 2015-12-10
Repository revision: a1e076240c71373954de0579bf4b026891df8a98
Configured using:
 'configure --enable-checking --config-cache 'CFLAGS=-O0 -g3''

Configured features:
SOUND NOTIFY LIBSELINUX LIBXML2 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Help

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Unable to load color "color-27" [2 times]
Unable to load color "color-28" [2 times]
Unable to load color "color-29" [2 times]
Unable to load color "color-30" [2 times]
Unable to load color "color-31" [2 times]
Unable to load color "color-32" [2 times]
Unable to load color "color-33" [2 times]
When done with this frame, type C-x 5 0
Type C-x 1 to delete the help window.


Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils color server
term/xterm xterm byte-opt gv bytecomp byte-compile cl-extra help-mode
easymenu cl-loaddefs pcase cl-lib cconv time-date mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select mouse jit-lock font-lock syntax
facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote inotify multi-tty
make-network-process emacs)

Memory information:
((conses 16 120356 5071)
 (symbols 48 27849 0)
 (miscs 40 36 100)
 (strings 32 31989 4591)
 (string-bytes 1 581177)
 (vectors 16 10614)
 (vector-slots 8 389733 2151)
 (floats 8 267 501)
 (intervals 56 231 96)
 (buffers 976 13)
 (heap 1024 21302 815))

[-- Attachment #2: Type: text/html, Size: 4871 bytes --]

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

[Eli Zaretskii]

> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Sat, 12 Dec 2015 21:49:10 +0000
> 
> I have TERM set to 'xterm-256color'.
> 
> I started emacs with `/mnt/emacs-25/src/emacs -Q`
> 
> I confirmed that 256 colors "worked" by doing M-x list-colors-display
> RET, and noting that there were about 256 lines of output, with plenty
> of different colors.
> 
> I typed M-x server-start RET.
> 
> In another terminal on the same machine, I typed `TERM=xterm
> /mnt/emacs-25/lib-src/emacsclient -c`. That displayed a *scratch*
> buffer, as I'd expected.

Out of curiosity: why would you want to downgrade the number of colors
in the client frames wrt the number supported by the server?

> In that new frame, I typed `M-x list-colors-display RET`. I noticed
> that now there were only eight lines of output.
> 
> I did C-x 5 0 to delete the new frame, then back in the original frame
> again typed `M-x list-colors-display RET`, and noted that there were
> still only eight lines of output.

This was never supported, we always assumed that the number of colors
on all tty frames is the same.

Does the patch below fix the problem?

diff --git a/src/term.c b/src/term.c
index 6ab611d..b7d9d5c 100644
--- a/src/term.c
+++ b/src/term.c
@@ -2041,16 +2041,6 @@ TERMINAL does not refer to a text terminal.  */)
 
 #ifndef DOS_NT
 
-/* Declare here rather than in the function, as in the rest of Emacs,
-   to work around an HPUX compiler bug (?). See
-   http://lists.gnu.org/archive/html/emacs-devel/2007-08/msg00410.html  */
-static int default_max_colors;
-static int default_max_pairs;
-static int default_no_color_video;
-static char *default_orig_pair;
-static char *default_set_foreground;
-static char *default_set_background;
-
 /* Save or restore the default color-related capabilities of this
    terminal.  */
 static void
@@ -2059,21 +2049,21 @@ tty_default_color_capabilities (struct tty_display_info *tty, bool save)
 
   if (save)
     {
-      dupstring (&default_orig_pair, tty->TS_orig_pair);
-      dupstring (&default_set_foreground, tty->TS_set_foreground);
-      dupstring (&default_set_background, tty->TS_set_background);
-      default_max_colors = tty->TN_max_colors;
-      default_max_pairs = tty->TN_max_pairs;
-      default_no_color_video = tty->TN_no_color_video;
+      dupstring (&tty->default_orig_pair, tty->TS_orig_pair);
+      dupstring (&tty->default_set_foreground, tty->TS_set_foreground);
+      dupstring (&tty->default_set_background, tty->TS_set_background);
+      tty->default_max_colors = tty->TN_max_colors;
+      tty->default_max_pairs = tty->TN_max_pairs;
+      tty->default_no_color_video = tty->TN_no_color_video;
     }
   else
     {
-      tty->TS_orig_pair = default_orig_pair;
-      tty->TS_set_foreground = default_set_foreground;
-      tty->TS_set_background = default_set_background;
-      tty->TN_max_colors = default_max_colors;
-      tty->TN_max_pairs = default_max_pairs;
-      tty->TN_no_color_video = default_no_color_video;
+      tty->TS_orig_pair = tty->default_orig_pair;
+      tty->TS_set_foreground = tty->default_set_foreground;
+      tty->TS_set_background = tty->default_set_background;
+      tty->TN_max_colors = tty->default_max_colors;
+      tty->TN_max_pairs = tty->default_max_pairs;
+      tty->TN_no_color_video = tty->default_no_color_video;
     }
 }
 
@@ -4131,6 +4121,7 @@ use the Bourne shell command 'TERM=...; export TERM' (C-shell:\n\
     }
 
   tty_default_color_capabilities (tty, 1);
+  tty->previous_color_mode = -1;
 
   MagicWrap (tty) = tgetflag ("xn");
   /* Since we make MagicWrap terminals look like AutoWrap, we need to have
@@ -4496,12 +4487,6 @@ bigger, or it may make it blink, or it may do nothing at all.  */);
   defsubr (&Sgpm_mouse_stop);
 #endif /* HAVE_GPM */
 
-#ifndef DOS_NT
-  default_orig_pair = NULL;
-  default_set_foreground = NULL;
-  default_set_background = NULL;
-#endif /* !DOS_NT */
-
   encode_terminal_src = NULL;
   encode_terminal_dst = NULL;
 
diff --git a/src/termchar.h b/src/termchar.h
index 06c0427..b07b78f 100644
--- a/src/termchar.h
+++ b/src/termchar.h
@@ -161,6 +161,14 @@ struct tty_display_info
   const char *TS_set_foreground;
   const char *TS_set_background;
 
+  /* Default values recorded when the tty was initialized.  */
+  char *default_orig_pair;
+  char *default_set_foreground;
+  char *default_set_background;
+  int default_max_colors;
+  int default_max_pairs;
+  int default_no_color_video;
+
   int TF_hazeltine;             /* termcap hz flag. */
   int TF_insmode_motion;        /* termcap mi flag: can move while in insert mode. */
   int TF_standout_motion;       /* termcap mi flag: can move while in standout mode. */

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

[Eric Hanchrow]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Sun, Dec 13, 2015 at 9:30 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Out of curiosity: why would you want to downgrade the number of colors
> in the client frames wrt the number supported by the server?
>

It wasn't intentional.  I was trying out a new terminal (a
"terminal-in-your-browser" feature that's part of the "Jupyter notebook" (
http://jupyter.org/).  I created one of those terminals on the machine on
which I was running emacs, and, in order to see it work, I started an
emacsclient.

>
> Does the patch below fix the problem?
>

It doesn't seem to make any difference.

[-- Attachment #2: Type: text/html, Size: 1093 bytes --]

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

[Eli Zaretskii]

> 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.

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

[Eli Zaretskii]

> 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?

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

[Eric Hanchrow]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

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?
>
>

[-- Attachment #2: Type: text/html, Size: 2367 bytes --]

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

[Eli Zaretskii]

> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Sun, 13 Dec 2015 18:47:32 +0000
> Cc: 22154@debbugs.gnu.org
> 
> I assume you meant `tty-color-mode-alist'.

No, I meant the value returned by tty-color-alist, which is stored in
the variable tty-defined-color-alist.

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

[Eric Hanchrow]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

On Sun, Dec 13, 2015 at 11:51 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > I assume you meant `tty-color-mode-alist'.
>
> No, I meant the value returned by tty-color-alist, which is stored in
> the variable tty-defined-color-alist.

Aha!  As Emily Litella says, "That's quite different" :-)

So I added some "message" calls, as described by the attached patch.
Here's what I see in *Messages* after simply running `emacs -Q`:

    terminal-init-xterm doin’ its thang.  (tty-color-alist) returns a
list of length 8.
    terminal-init-xterm is done.  (tty-color-alist) now returns a list
of length 256.
    For information about GNU Emacs and the GNU system, type C-h C-a.

And here's what I see after I create the new frame:

    You can run the command ‘server-start’ with M-x ser-s RET
    terminal-init-xterm doin’ its thang.  (tty-color-alist) returns a
list of length 256.
    terminal-init-xterm is done.  (tty-color-alist) now returns a list
of length 8.
    When done with this frame, type C-x 5 0

So clearly: xterm.el initialization _is_ getting called for the client
frame, and it _does_ modify tty-color-alist.

I've put the actual before-and-after values returned from
`(tty-color-alist)' into a second attachment, since the "before" value
is quite long.

[-- Attachment #2: 0001-Add-some-debugging-to-terminal-init-xterm.patch --]
[-- Type: application/octet-stream, Size: 1324 bytes --]

From b32560b4cdd2b56312f727df02fcc6ddd0bccbc6 Mon Sep 17 00:00:00 2001
From: Eric Hanchrow <eric.hanchrow@gmail.com>
Date: Sun, 13 Dec 2015 20:19:21 +0000
Subject: [PATCH] Add some debugging to terminal-init-xterm

---
 lisp/term/xterm.el | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 00ed027..fe24b85 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -752,6 +752,7 @@ xterm--push-map
 
 (defun terminal-init-xterm ()
   "Terminal initialization function for xterm."
+  (message "terminal-init-xterm doin' its thang.  (tty-color-alist) returns a list of length %s." (length (tty-color-alist)))
   ;; rxvt terminals sometimes set the TERM variable to "xterm", but
   ;; rxvt's keybindings are incompatible with xterm's. It is
   ;; better in that case to use rxvt's initialization function.
@@ -791,7 +792,9 @@ terminal-init-xterm
   ;; support it just ignore the sequence.
   (xterm--init-bracketed-paste-mode)
 
-  (run-hooks 'terminal-init-xterm-hook))
+  (run-hooks 'terminal-init-xterm-hook)
+  (message "terminal-init-xterm is done.  (tty-color-alist) now returns a list of length %s." (length (tty-color-alist)))
+)
 
 (defun xterm--init-modify-other-keys ()
   "Terminal initialization for xterm's modifyOtherKeys support."
-- 
2.4.3


[-- Attachment #3: after.el --]
[-- Type: application/octet-stream, Size: 193 bytes --]

(("black" 0 0 0 0) ("red" 1 52685 0 0) ("green" 2 0 52685 0) ("yellow" 3 52685 52685 0) ("blue" 4 0 0 61166) ("magenta" 5 52685 0 52685) ("cyan" 6 0 52685 52685) ("white" 7 58853 58853 58853))

[-- Attachment #4: before.el --]
[-- Type: application/octet-stream, Size: 8486 bytes --]

(("black" 0 0 0 0) ("red" 1 52685 0 0) ("green" 2 0 52685 0) ("yellow" 3 52685 52685 0) ("blue" 4 0 0 61166) ("magenta" 5 52685 0 52685) ("cyan" 6 0 52685 52685) ("white" 7 58853 58853 58853) ("brightblack" 8 32639 32639 32639) ("brightred" 9 65535 0 0) ("brightgreen" 10 0 65535 0) ("brightyellow" 11 65535 65535 0) ("brightblue" 12 23644 23644 65535) ("brightmagenta" 13 65535 0 65535) ("brightcyan" 14 0 65535 65535) ("brightwhite" 15 65535 65535 65535) ("color-16" 16 0 0 0) ("color-17" 17 0 0 24415) ("color-18" 18 0 0 34695) ("color-19" 19 0 0 44975) ("color-20" 20 0 0 55255) ("color-21" 21 0 0 65535) ("color-22" 22 0 24415 0) ("color-23" 23 0 24415 24415) ("color-24" 24 0 24415 34695) ("color-25" 25 0 24415 44975) ("color-26" 26 0 24415 55255) ("color-27" 27 0 24415 65535) ("color-28" 28 0 34695 0) ("color-29" 29 0 34695 24415) ("color-30" 30 0 34695 34695) ("color-31" 31 0 34695 44975) ("color-32" 32 0 34695 55255) ("color-33" 33 0 34695 65535) ("color-34" 34 0 44975 0) ("color-35" 35 0 44975 24415) ("color-36" 36 0 44975 34695) ("color-37" 37 0 44975 44975) ("color-38" 38 0 44975 55255) ("color-39" 39 0 44975 65535) ("color-40" 40 0 55255 0) ("color-41" 41 0 55255 24415) ("color-42" 42 0 55255 34695) ("color-43" 43 0 55255 44975) ("color-44" 44 0 55255 55255) ("color-45" 45 0 55255 65535) ("color-46" 46 0 65535 0) ("color-47" 47 0 65535 24415) ("color-48" 48 0 65535 34695) ("color-49" 49 0 65535 44975) ("color-50" 50 0 65535 55255) ("color-51" 51 0 65535 65535) ("color-52" 52 24415 0 0) ("color-53" 53 24415 0 24415) ("color-54" 54 24415 0 34695) ("color-55" 55 24415 0 44975) ("color-56" 56 24415 0 55255) ("color-57" 57 24415 0 65535) ("color-58" 58 24415 24415 0) ("color-59" 59 24415 24415 24415) ("color-60" 60 24415 24415 34695) ("color-61" 61 24415 24415 44975) ("color-62" 62 24415 24415 55255) ("color-63" 63 24415 24415 65535) ("color-64" 64 24415 34695 0) ("color-65" 65 24415 34695 24415) ("color-66" 66 24415 34695 34695) ("color-67" 67 24415 34695 44975) ("color-68" 68 24415 34695 55255) ("color-69" 69 24415 34695 65535) ("color-70" 70 24415 44975 0) ("color-71" 71 24415 44975 24415) ("color-72" 72 24415 44975 34695) ("color-73" 73 24415 44975 44975) ("color-74" 74 24415 44975 55255) ("color-75" 75 24415 44975 65535) ("color-76" 76 24415 55255 0) ("color-77" 77 24415 55255 24415) ("color-78" 78 24415 55255 34695) ("color-79" 79 24415 55255 44975) ("color-80" 80 24415 55255 55255) ("color-81" 81 24415 55255 65535) ("color-82" 82 24415 65535 0) ("color-83" 83 24415 65535 24415) ("color-84" 84 24415 65535 34695) ("color-85" 85 24415 65535 44975) ("color-86" 86 24415 65535 55255) ("color-87" 87 24415 65535 65535) ("color-88" 88 34695 0 0) ("color-89" 89 34695 0 24415) ("color-90" 90 34695 0 34695) ("color-91" 91 34695 0 44975) ("color-92" 92 34695 0 55255) ("color-93" 93 34695 0 65535) ("color-94" 94 34695 24415 0) ("color-95" 95 34695 24415 24415) ("color-96" 96 34695 24415 34695) ("color-97" 97 34695 24415 44975) ("color-98" 98 34695 24415 55255) ("color-99" 99 34695 24415 65535) ("color-100" 100 34695 34695 0) ("color-101" 101 34695 34695 24415) ("color-102" 102 34695 34695 34695) ("color-103" 103 34695 34695 44975) ("color-104" 104 34695 34695 55255) ("color-105" 105 34695 34695 65535) ("color-106" 106 34695 44975 0) ("color-107" 107 34695 44975 24415) ("color-108" 108 34695 44975 34695) ("color-109" 109 34695 44975 44975) ("color-110" 110 34695 44975 55255) ("color-111" 111 34695 44975 65535) ("color-112" 112 34695 55255 0) ("color-113" 113 34695 55255 24415) ("color-114" 114 34695 55255 34695) ("color-115" 115 34695 55255 44975) ("color-116" 116 34695 55255 55255) ("color-117" 117 34695 55255 65535) ("color-118" 118 34695 65535 0) ("color-119" 119 34695 65535 24415) ("color-120" 120 34695 65535 34695) ("color-121" 121 34695 65535 44975) ("color-122" 122 34695 65535 55255) ("color-123" 123 34695 65535 65535) ("color-124" 124 44975 0 0) ("color-125" 125 44975 0 24415) ("color-126" 126 44975 0 34695) ("color-127" 127 44975 0 44975) ("color-128" 128 44975 0 55255) ("color-129" 129 44975 0 65535) ("color-130" 130 44975 24415 0) ("color-131" 131 44975 24415 24415) ("color-132" 132 44975 24415 34695) ("color-133" 133 44975 24415 44975) ("color-134" 134 44975 24415 55255) ("color-135" 135 44975 24415 65535) ("color-136" 136 44975 34695 0) ("color-137" 137 44975 34695 24415) ("color-138" 138 44975 34695 34695) ("color-139" 139 44975 34695 44975) ("color-140" 140 44975 34695 55255) ("color-141" 141 44975 34695 65535) ("color-142" 142 44975 44975 0) ("color-143" 143 44975 44975 24415) ("color-144" 144 44975 44975 34695) ("color-145" 145 44975 44975 44975) ("color-146" 146 44975 44975 55255) ("color-147" 147 44975 44975 65535) ("color-148" 148 44975 55255 0) ("color-149" 149 44975 55255 24415) ("color-150" 150 44975 55255 34695) ("color-151" 151 44975 55255 44975) ("color-152" 152 44975 55255 55255) ("color-153" 153 44975 55255 65535) ("color-154" 154 44975 65535 0) ("color-155" 155 44975 65535 24415) ("color-156" 156 44975 65535 34695) ("color-157" 157 44975 65535 44975) ("color-158" 158 44975 65535 55255) ("color-159" 159 44975 65535 65535) ("color-160" 160 55255 0 0) ("color-161" 161 55255 0 24415) ("color-162" 162 55255 0 34695) ("color-163" 163 55255 0 44975) ("color-164" 164 55255 0 55255) ("color-165" 165 55255 0 65535) ("color-166" 166 55255 24415 0) ("color-167" 167 55255 24415 24415) ("color-168" 168 55255 24415 34695) ("color-169" 169 55255 24415 44975) ("color-170" 170 55255 24415 55255) ("color-171" 171 55255 24415 65535) ("color-172" 172 55255 34695 0) ("color-173" 173 55255 34695 24415) ("color-174" 174 55255 34695 34695) ("color-175" 175 55255 34695 44975) ("color-176" 176 55255 34695 55255) ("color-177" 177 55255 34695 65535) ("color-178" 178 55255 44975 0) ("color-179" 179 55255 44975 24415) ("color-180" 180 55255 44975 34695) ("color-181" 181 55255 44975 44975) ("color-182" 182 55255 44975 55255) ("color-183" 183 55255 44975 65535) ("color-184" 184 55255 55255 0) ("color-185" 185 55255 55255 24415) ("color-186" 186 55255 55255 34695) ("color-187" 187 55255 55255 44975) ("color-188" 188 55255 55255 55255) ("color-189" 189 55255 55255 65535) ("color-190" 190 55255 65535 0) ("color-191" 191 55255 65535 24415) ("color-192" 192 55255 65535 34695) ("color-193" 193 55255 65535 44975) ("color-194" 194 55255 65535 55255) ("color-195" 195 55255 65535 65535) ("color-196" 196 65535 0 0) ("color-197" 197 65535 0 24415) ("color-198" 198 65535 0 34695) ("color-199" 199 65535 0 44975) ("color-200" 200 65535 0 55255) ("color-201" 201 65535 0 65535) ("color-202" 202 65535 24415 0) ("color-203" 203 65535 24415 24415) ("color-204" 204 65535 24415 34695) ("color-205" 205 65535 24415 44975) ("color-206" 206 65535 24415 55255) ("color-207" 207 65535 24415 65535) ("color-208" 208 65535 34695 0) ("color-209" 209 65535 34695 24415) ("color-210" 210 65535 34695 34695) ("color-211" 211 65535 34695 44975) ("color-212" 212 65535 34695 55255) ("color-213" 213 65535 34695 65535) ("color-214" 214 65535 44975 0) ("color-215" 215 65535 44975 24415) ("color-216" 216 65535 44975 34695) ("color-217" 217 65535 44975 44975) ("color-218" 218 65535 44975 55255) ("color-219" 219 65535 44975 65535) ("color-220" 220 65535 55255 0) ("color-221" 221 65535 55255 24415) ("color-222" 222 65535 55255 34695) ("color-223" 223 65535 55255 44975) ("color-224" 224 65535 55255 55255) ("color-225" 225 65535 55255 65535) ("color-226" 226 65535 65535 0) ("color-227" 227 65535 65535 24415) ("color-228" 228 65535 65535 34695) ("color-229" 229 65535 65535 44975) ("color-230" 230 65535 65535 55255) ("color-231" 231 65535 65535 65535) ("color-232" 232 2056 2056 2056) ("color-233" 233 4626 4626 4626) ("color-234" 234 7196 7196 7196) ("color-235" 235 9766 9766 9766) ("color-236" 236 12336 12336 12336) ("color-237" 237 14906 14906 14906) ("color-238" 238 17476 17476 17476) ("color-239" 239 20046 20046 20046) ("color-240" 240 22616 22616 22616) ("color-241" 241 25186 25186 25186) ("color-242" 242 27756 27756 27756) ("color-243" 243 30326 30326 30326) ("color-244" 244 32896 32896 32896) ("color-245" 245 35466 35466 35466) ("color-246" 246 38036 38036 38036) ("color-247" 247 40606 40606 40606) ("color-248" 248 43176 43176 43176) ("color-249" 249 45746 45746 45746) ("color-250" 250 48316 48316 48316) ("color-251" 251 50886 50886 50886) ("color-252" 252 53456 53456 53456) ("color-253" 253 56026 56026 56026) ("color-254" 254 58596 58596 58596) ("color-255" 255 61166 61166 61166))

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

[Eli Zaretskii]

> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Sun, 13 Dec 2015 12:26:10 -0800
> Cc: 22154@debbugs.gnu.org
> 
>     You can run the command ‘server-start’ with M-x ser-s RET
>     terminal-init-xterm doin’ its thang.  (tty-color-alist) returns a
> list of length 256.
>     terminal-init-xterm is done.  (tty-color-alist) now returns a list
> of length 8.
>     When done with this frame, type C-x 5 0
> 
> So clearly: xterm.el initialization _is_ getting called for the client
> frame, and it _does_ modify tty-color-alist.

Right.  I guess we will have to make tty-defined-color-alist
terminal-specific, or something.  This will have to wait until after
25.1, sorry.

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

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Hanchrow <eric.hanchrow@gmail.com>
>> Date: Sat, 12 Dec 2015 21:49:10 +0000
>> 
>> I have TERM set to 'xterm-256color'.
>> 
>> I started emacs with `/mnt/emacs-25/src/emacs -Q`
>> 
>> I confirmed that 256 colors "worked" by doing M-x list-colors-display
>> RET, and noting that there were about 256 lines of output, with plenty
>> of different colors.
>> 
>> I typed M-x server-start RET.
>> 
>> In another terminal on the same machine, I typed `TERM=xterm
>> /mnt/emacs-25/lib-src/emacsclient -c`. That displayed a *scratch*
>> buffer, as I'd expected.
>
> Out of curiosity: why would you want to downgrade the number of colors
> in the client frames wrt the number supported by the server?
>
>> In that new frame, I typed `M-x list-colors-display RET`. I noticed
>> that now there were only eight lines of output.
>> 
>> I did C-x 5 0 to delete the new frame, then back in the original frame
>> again typed `M-x list-colors-display RET`, and noted that there were
>> still only eight lines of output.
>
> This was never supported, we always assumed that the number of colors
> on all tty frames is the same.

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...

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

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Hanchrow <eric.hanchrow@gmail.com>
>> Date: Sat, 12 Dec 2015 21:49:10 +0000
>> 
>> I have TERM set to 'xterm-256color'.
>> 
>> I started emacs with `/mnt/emacs-25/src/emacs -Q`
>> 
>> I confirmed that 256 colors "worked" by doing M-x list-colors-display
>> RET, and noting that there were about 256 lines of output, with plenty
>> of different colors.
>> 
>> I typed M-x server-start RET.
>> 
>> In another terminal on the same machine, I typed `TERM=xterm
>> /mnt/emacs-25/lib-src/emacsclient -c`. That displayed a *scratch*
>> buffer, as I'd expected.
>
> Out of curiosity: why would you want to downgrade the number of colors
> in the client frames wrt the number supported by the server?
>
>> In that new frame, I typed `M-x list-colors-display RET`. I noticed
>> that now there were only eight lines of output.
>> 
>> I did C-x 5 0 to delete the new frame, then back in the original frame
>> again typed `M-x list-colors-display RET`, and noted that there were
>> still only eight lines of output.
>
> This was never supported, we always assumed that the number of colors
> on all tty frames is the same.

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...

Date: Mon, 14 Dec 2015 01:24:09 -0500

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?

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

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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:

What exactly is the problem that your patch fixes?
I don't remember all the details, but having multiple terminal frames
running on multiple kinds of terminals, with different color depths and
even background modes was heavily tested when the multi-tty work was
going on.  One of the usual tests was to have rxvt with both 8 and 256
colors and white on black and black on white (rxvt not xterm because
rxvt sets an environment variable with the default color and emacs can
decide if it's a light or dark background based on that).  It worked
fine.
Did something break meanwhile or you are dealing with some new thing
that was not dealt with back then? 

Thanks

        --Dan

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

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Cc: eric.hanchrow@gmail.com,  22154@debbugs.gnu.org
> Date: Mon, 14 Dec 2015 11:39:39 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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:
> 
> 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.

> I don't remember all the details, but having multiple terminal frames
> running on multiple kinds of terminals, with different color depths and
> even background modes was heavily tested when the multi-tty work was
> going on.  One of the usual tests was to have rxvt with both 8 and 256
> colors and white on black and black on white (rxvt not xterm because
> rxvt sets an environment variable with the default color and emacs can
> decide if it's a light or dark background based on that).  It worked
> fine.
> Did something break meanwhile or you are dealing with some new thing
> that was not dealt with back then? 

I don't know.  It's possible that the fact that set_tty_color_mode is
now called as part of redisplay exposed some issue.

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?

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

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Cc: eric.hanchrow@gmail.com,  22154@debbugs.gnu.org
>> Date: Mon, 14 Dec 2015 11:39:39 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> 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:
>> 
>> 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?

>
>> I don't remember all the details, but having multiple terminal frames
>> running on multiple kinds of terminals, with different color depths and
>> even background modes was heavily tested when the multi-tty work was
>> going on.  One of the usual tests was to have rxvt with both 8 and 256
>> colors and white on black and black on white (rxvt not xterm because
>> rxvt sets an environment variable with the default color and emacs can
>> decide if it's a light or dark background based on that).  It worked
>> fine.
>> Did something break meanwhile or you are dealing with some new thing
>> that was not dealt with back then? 
>
> I don't know.  It's possible that the fact that set_tty_color_mode is
> now called as part of redisplay exposed some issue.
>
> 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
M-x list-faces-display looks correct on all 3 of the simultaneously.
Editing C code in a file displayed on the 3 terminals looks fine,
everything gets fontified with the expected colors everywhere.
Unfortunately I don't have a more recent emacs version on this machine...

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

[Eli Zaretskii]

> 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?

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

[Eric Hanchrow]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On Tue, Dec 15, 2015 at 8:05 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Eric, can you test your scenario with Emacs 24.5, please?
>
> The problem also happens in 24.5.

I also noticed that, once the problem has happened, if I close the
emacsclient frame with C-x 5 0, then create another one with
TERM=xterm-256color, the colors in the *Colors* buffer are restored.

[-- Attachment #2: Type: text/html, Size: 738 bytes --]

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

[Eli Zaretskii]

> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Tue, 15 Dec 2015 16:37:19 +0000
> Cc: 22154@debbugs.gnu.org
> 
> The problem also happens in 24.5. 

Thanks.  So, Dan, you should be able to reproduce it.

> I also noticed that, once the problem has happened, if I close the emacsclient
> frame with C-x 5 0, then create another one with TERM=xterm-256color, the
> colors in the *Colors* buffer are restored.

Yes, of course: doing that initializes a 256-color xterm again, and
that re-fills the list of colors with what was there originally.

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

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

OK, great.  That is actually a very important use-case, and more in line
with what people normally do.  It's good that it still works.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

I haven't tried to reproduce the bug, but it seems like you never
applied your per-tty colour patch which (from my limited knowledge of
the tty stuff) sounded like a good idea.  (It didn't fix the reported
problem, but looks more correct, anyway.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dan Nicolaescu <dann@gnu.org>,  eric.hanchrow@gmail.com,
>   22154@debbugs.gnu.org
> Date: Sat, 05 Sep 2020 16:50:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> I haven't tried to reproduce the bug, but it seems like you never
> applied your per-tty colour patch which (from my limited knowledge of
> the tty stuff) sounded like a good idea.  (It didn't fix the reported
> problem, but looks more correct, anyway.)

I didn't apply it because it solved only a part of the problem.  The
solution to this bug needs to solve the rest as well.