GNU bug report logs - #22154
25.0.50; emacsclient -c "breaks" 256-color display in server

Previous Next

To reply to this bug, email your comments to 22154 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 25.0.50; emacsclient -c "breaks" 256-color display in server
Date: Sat, 12 Dec 2015 21:49:10 +0000

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #8 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 19:30:05 +0200

> From: Eric Hanchrow <eric.hanchrow <at> 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. */

Message #11 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 10:05:20 -0800

[Message part 1 (text/plain, inline)]

On Sun, Dec 13, 2015 at 9:30 AM Eli Zaretskii <eliz <at> 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.

[Message part 2 (text/html, inline)]

Message #14 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 20:17:11 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sun, 13 Dec 2015 10:05:20 -0800
> Cc: 22154 <at> 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.

Message #17 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: eric.hanchrow <at> gmail.com
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 20:37:26 +0200

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

Message #20 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 18:47:32 +0000

[Message part 1 (text/plain, inline)]

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

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

[Message part 2 (text/html, inline)]

Message #23 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 21:51:18 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sun, 13 Dec 2015 18:47:32 +0000
> Cc: 22154 <at> 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.

Message #26 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 12:26:10 -0800

[Message part 1 (text/plain, inline)]

On Sun, Dec 13, 2015 at 11:51 AM Eli Zaretskii <eliz <at> 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.

[0001-Add-some-debugging-to-terminal-init-xterm.patch (application/octet-stream, attachment)]

[after.el (application/octet-stream, attachment)]

[before.el (application/octet-stream, attachment)]

Message #29 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Sun, 13 Dec 2015 22:49:44 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sun, 13 Dec 2015 12:26:10 -0800
> Cc: 22154 <at> 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.

Message #32 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Eric Hanchrow <eric.hanchrow <at> gmail.com>, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Mon, 14 Dec 2015 01:21:26 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Hanchrow <eric.hanchrow <at> 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...

Message #35 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Eric Hanchrow <eric.hanchrow <at> gmail.com>, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Mon, 14 Dec 2015 01:35:43 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Hanchrow <eric.hanchrow <at> 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

Message #38 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: eric.hanchrow <at> gmail.com, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Mon, 14 Dec 2015 17:56:43 +0200

> From: Dan Nicolaescu <dann <at> gnu.org>
> Cc: Eric Hanchrow <eric.hanchrow <at> gmail.com>,  22154 <at> 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?

Message #41 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eric.hanchrow <at> gmail.com, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Mon, 14 Dec 2015 11:39:39 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dan Nicolaescu <dann <at> gnu.org>
>> Cc: Eric Hanchrow <eric.hanchrow <at> gmail.com>,  22154 <at> 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

Message #44 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: eric.hanchrow <at> gmail.com, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Mon, 14 Dec 2015 19:02:34 +0200

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

Message #47 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eric.hanchrow <at> gmail.com, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Tue, 15 Dec 2015 00:46:08 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

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

Message #50 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: eric.hanchrow <at> gmail.com, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Tue, 15 Dec 2015 18:05:11 +0200

> From: Dan Nicolaescu <dann <at> gnu.org>
> Cc: eric.hanchrow <at> gmail.com,  22154 <at> 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?

Message #53 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Dan Nicolaescu <dann <at> gnu.org>
Cc: 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Tue, 15 Dec 2015 16:37:19 +0000

[Message part 1 (text/plain, inline)]

On Tue, Dec 15, 2015 at 8:05 AM Eli Zaretskii <eliz <at> 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.

[Message part 2 (text/html, inline)]

Message #56 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Cc: dann <at> gnu.org, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Tue, 15 Dec 2015 18:40:43 +0200

> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Tue, 15 Dec 2015 16:37:19 +0000
> Cc: 22154 <at> 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.

Message #59 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eric.hanchrow <at> gmail.com, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50;
 emacsclient -c "breaks" 256-color display in server
Date: Thu, 17 Dec 2015 23:59:08 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dan Nicolaescu <dann <at> gnu.org>
>> Cc: eric.hanchrow <at> gmail.com,  22154 <at> 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.

Message #62 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dan Nicolaescu <dann <at> gnu.org>, eric.hanchrow <at> gmail.com,
 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50; emacsclient -c "breaks" 256-color display
 in server
Date: Sat, 05 Sep 2020 16:50:29 +0200

Eli Zaretskii <eliz <at> 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

Message #65 received at 22154 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: dann <at> gnu.org, eric.hanchrow <at> gmail.com, 22154 <at> debbugs.gnu.org
Subject: Re: bug#22154: 25.0.50; emacsclient -c "breaks" 256-color display
 in server
Date: Sat, 05 Sep 2020 18:31:53 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Dan Nicolaescu <dann <at> gnu.org>,  eric.hanchrow <at> gmail.com,
>   22154 <at> debbugs.gnu.org
> Date: Sat, 05 Sep 2020 16:50:29 +0200
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.