colours in client on xterm (if an X frame is open at same time)

colours in client on xterm (if an X frame is open at same time)

[Ulrich Mueller]

Hi,

I wonder if the following is a feature or a bug: If I run
"emacsclient -t" in an xterm, then I get a grey background if an
X frame is open at the same time (this didn't happen with 23.1).

To be specific, here is a session that illustrates the behaviour:

   $ emacs -Q --daemon
   ("emacs")
   Starting Emacs daemon.
   $ emacsclient -t

This looks "normal": the window has a white background, and the
modeline has a greenish background.
Screenshot: <http://dev.gentoo.org/~ulm/screenshot/1.png>

   [delete the frame with C-x 5 0]
   $ emacsclient -n -c
   [don't delete the X frame]
   $ emacsclient -t

Now the window has grey background and the modeline is black. Is it
intended that it should look like this?
Screenshot: <http://dev.gentoo.org/~ulm/screenshot/2.png>

If I set TERM=vt200 (instead of TERM=xterm) before starting
emacsclient, then it looks like the first screenshot again.

Ulrich

Re: colours in client on xterm (if an X frame is open at same time)

[Dan Nicolaescu]

Ulrich Mueller <ulm@gentoo.org> writes:

  > Hi,
  > 
  > I wonder if the following is a feature or a bug: If I run
  > "emacsclient -t" in an xterm, then I get a grey background if an
  > X frame is open at the same time (this didn't happen with 23.1).
  > 
  > To be specific, here is a session that illustrates the behaviour:
  > 
  >    $ emacs -Q --daemon
  >    ("emacs")
  >    Starting Emacs daemon.
  >    $ emacsclient -t
  > 
  > This looks "normal": the window has a white background, and the
  > modeline has a greenish background.
  > Screenshot: <http://dev.gentoo.org/~ulm/screenshot/1.png>

Green is not the default face for the modeline for any display, so 
something is strange in your setup.

Re: colours in client on xterm (if an X frame is open at same time)

[Eric Hanchrow]

On Thu, Jan 7, 2010 at 3:26 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> I wonder if the following is a feature or a bug: If I run
> "emacsclient -t" in an xterm, then I get a grey background if an
> X frame is open at the same time (this didn't happen with 23.1).

I could not reproduce this behavior, and yet I've seen something
vaguely similar: I generally have running an emacs that I've started
via "emacs -nw"; I connect to it with "emacsclient --tty" (and then
disconnect) a few times a day.  That works fine, with no strange
colors.  But occasionally I connect to it via "emacsclient -c", which
itself works fine -- but thenceforth, console frames that I create
with "emacsclient --tty" have a light-colored background -- and
killing the X frame doesn't fix that problem.  Only restarting emacs
fixes it.

Re: colours in client on xterm (if an X frame is open at same time)

[Ulrich Mueller]

>>>>> On Thu, 7 Jan 2010, Dan Nicolaescu wrote:

> Green is not the default face for the modeline for any display, so 
> something is strange in your setup.

Right, this particular colour was taken from my X settings
("*HighlightColor: DarkSeaGreen2"). I've repeated the test with empty
X resources, new screenshots are here:
<http://dev.gentoo.org/~ulm/screenshot/>

Anyway, my point was, why are the colours _different_ in the second
case? Especially, why is the background grey?

Ulrich

Re: colours in client on xterm (if an X frame is open at same time)

[Dan Nicolaescu]

Ulrich Mueller <ulm@gentoo.org> writes:

  > >>>>> On Thu, 7 Jan 2010, Dan Nicolaescu wrote:
  > 
  > > Green is not the default face for the modeline for any display, so 
  > > something is strange in your setup.
  > 
  > Right, this particular colour was taken from my X settings
  > ("*HighlightColor: DarkSeaGreen2"). I've repeated the test with empty
  > X resources, new screenshots are here:
  > <http://dev.gentoo.org/~ulm/screenshot/>
  > 
  > Anyway, my point was, why are the colours _different_ in the second
  > case? Especially, why is the background grey?

It should not be.   I can't reproduce it here, but by emacs is about 2
weeks old.

In the grey case, do you get something odd if you do 
a describe-face for the default face?

Is this something new? Do you get the same behavior with 23.1?
If not, then doing a binary search for the patch that broke it is your
best bet...

Re: colours in client on xterm (if an X frame is open at same time)

[Jan Djärv]

Ulrich Mueller skrev:
>>>>>> On Thu, 7 Jan 2010, Dan Nicolaescu wrote:
> 
>> Green is not the default face for the modeline for any display, so 
>> something is strange in your setup.
> 
> Right, this particular colour was taken from my X settings
> ("*HighlightColor: DarkSeaGreen2"). I've repeated the test with empty
> X resources, new screenshots are here:
> <http://dev.gentoo.org/~ulm/screenshot/>
> 
> Anyway, my point was, why are the colours _different_ in the second
> case? Especially, why is the background grey?
> 

The terminal frame defines the default face with unspecified-bg.
But when you start the X frame, the default face has background white (or 
rather the X pixel value for white).
This face is still realized when you start the second terminal face. 
Apparently pixel value for "white" in X translates to gray in an xterm.  I 
don't know exactly how the pixel values in the terminal case gets translated.

	Jan D.

Re: colours in client on xterm (if an X frame is open at same time)

[Ulrich Mueller]

>>>>> On Thu, 7 Jan 2010, Dan Nicolaescu wrote:

>> Anyway, my point was, why are the colours _different_ in the second
>> case? Especially, why is the background grey?

> It should not be.   I can't reproduce it here, but by emacs is about
> 2 weeks old.

> In the grey case, do you get something odd if you do a describe-face
> for the default face?

Differences between normal and grey case are:

   -    Foreground: unspecified-fg
   -    Background: unspecified-bg
   +    Foreground: black
   +    Background: white

   -          Font: unspecified
   -       Fontset: nil
   +          Font: #<font-spec nil nil nil nil nil nil nil nil nil nil nil nil ((user-spec . monospace-12))>
   +       Fontset: -unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-fontset-startup

> Is this something new? Do you get the same behavior with 23.1?
> If not, then doing a binary search for the patch that broke it is your
> best bet...

I had hoped that the bisecting could be avoided, but here we go.

The "grey background" started with revision 99013 (and reverting this
changeset in the trunk of today brings back the old behaviour):

   revno: 99013
   committer: Dan Nicolaescu <dann@ics.uci.edu>
   branch nick: trunk
   timestamp: Mon 2009-12-07 06:30:30 +0000
   message:
     Get the background mode from the terminal for xterm, and set
     faces accordingly.
     * term/xterm.el (xterm-set-background-mode): New function.
     (terminal-init-xterm): Use it in case xterm supports background
     color queries.  Recompute faces after getting the background
     color.

BTW, I use xterm version 250, in case that it matters.

Ulrich

Re: colours in client on xterm (if an X frame is open at same time)

[Dan Nicolaescu]

Jan Djärv <jan.h.d@swipnet.se> writes:

  > Ulrich Mueller skrev:
  > >>>>>> On Thu, 7 Jan 2010, Dan Nicolaescu wrote:
  > >
  > >> Green is not the default face for the modeline for any display, so
  > >> something is strange in your setup.
  > >
  > > Right, this particular colour was taken from my X settings
  > > ("*HighlightColor: DarkSeaGreen2"). I've repeated the test with empty
  > > X resources, new screenshots are here:
  > > <http://dev.gentoo.org/~ulm/screenshot/>
  > >
  > > Anyway, my point was, why are the colours _different_ in the second
  > > case? Especially, why is the background grey?
  > >
  > 
  > The terminal frame defines the default face with unspecified-bg.
  > But when you start the X frame, the default face has background white
  > (or rather the X pixel value for white).
  > This face is still realized when you start the second terminal
  > face. Apparently pixel value for "white" in X translates to gray in an
  > xterm.  I don't know exactly how the pixel values in the terminal case
  > gets translated.

I only have access to 23.1 at the moment, and here the foreground and
background are unspecified-bg/fg in the second terminal frame.
Are you saying that is not the case in trunk now?  That seems to be the
problem then.
For a terminal the functions lisp/term/tty-colors.el:tty-color* do the translation.

Re: colours in client on xterm (if an X frame is open at same time)

[Dan Nicolaescu]

Ulrich Mueller <ulm@gentoo.org> writes:

  > >>>>> On Thu, 7 Jan 2010, Dan Nicolaescu wrote:
  > 
  > >> Anyway, my point was, why are the colours _different_ in the second
  > >> case? Especially, why is the background grey?
  > 
  > > It should not be.   I can't reproduce it here, but by emacs is about
  > > 2 weeks old.
  > 
  > > In the grey case, do you get something odd if you do a describe-face
  > > for the default face?
  > 
  > Differences between normal and grey case are:
  > 
  >    -    Foreground: unspecified-fg
  >    -    Background: unspecified-bg
  >    +    Foreground: black
  >    +    Background: white
  > 
  >    -          Font: unspecified
  >    -       Fontset: nil
  >    +          Font: #<font-spec nil nil nil nil nil nil nil nil nil nil nil nil ((user-spec . monospace-12))>
  >    +       Fontset: -unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-fontset-startup
  > 
  > > Is this something new? Do you get the same behavior with 23.1?
  > > If not, then doing a binary search for the patch that broke it is your
  > > best bet...
  > 
  > I had hoped that the bisecting could be avoided, but here we go.
  > 
  > The "grey background" started with revision 99013 (and reverting this
  > changeset in the trunk of today brings back the old behaviour):
  > 
  >    revno: 99013
  >    committer: Dan Nicolaescu <dann@ics.uci.edu>
  >    branch nick: trunk
  >    timestamp: Mon 2009-12-07 06:30:30 +0000
  >    message:
  >      Get the background mode from the terminal for xterm, and set
  >      faces accordingly.
  >      * term/xterm.el (xterm-set-background-mode): New function.
  >      (terminal-init-xterm): Use it in case xterm supports background
  >      color queries.  Recompute faces after getting the background
  >      color.

Thanks.

In your case the only effect that patch should have is to move the call
 (tty-set-up-initial-frame-faces) from before

(let ((coding-system-for-read 'binary)

to after it.

What happens in that `let' should not matter to your setup because your
background is light, so change 99013 should be a no-op in your case.

Hmmm, this is very odd...

Re: colours in client on xterm (if an X frame is open at same time)

[Ulrich Mueller]

>>>>> On Fri, 8 Jan 2010, Dan Nicolaescu wrote:

>> revno: 99013
>> committer: Dan Nicolaescu <dann@ics.uci.edu>
>> branch nick: trunk
>> timestamp: Mon 2009-12-07 06:30:30 +0000
>> message:
>> Get the background mode from the terminal for xterm, and set
>> faces accordingly.
>> * term/xterm.el (xterm-set-background-mode): New function.
>> (terminal-init-xterm): Use it in case xterm supports background
>> color queries.  Recompute faces after getting the background
>> color.

> Thanks.

> In your case the only effect that patch should have is to move the
> call (tty-set-up-initial-frame-faces) from before

> (let ((coding-system-for-read 'binary)

> to after it.

Right, if I move the call to (tty-set-up-initial-frame-faces) back to
its old location, i.e. immediately after (xterm-register-default-colors)
then the old behaviour is restored.

> What happens in that `let' should not matter to your setup because
> your background is light, so change 99013 should be a no-op in your
> case.

But it isn't ...

> Hmmm, this is very odd...

Re: colours in client on xterm (if an X frame is open at same time)

[Eli Zaretskii]

> Date: Fri, 8 Jan 2010 20:18:58 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: emacs-devel@gnu.org
> 
>   > In your case the only effect that patch should have is to move the call
>   >  (tty-set-up-initial-frame-faces) from before
>   > 
>   > (let ((coding-system-for-read 'binary)
>   > 
>   > to after it.
>  
> If I put back the `tty-set-up-initial-frame-faces' call (after
> `xterm-register-default-colors') and make current
> `tty-set-up-initial-frame-faces' conditional on detecting a dark
> background, then everything seems to work OK.  
> 
> Calling `tty-set-up-initial-frame-faces' twice in the dark background
> case is very ugly, but in case nobody finds a better solution soon I'll
> check in that change soon.

I wasn't following this thread.  I don't know if I can help, but
there's something I don't understand: is it the case that the new code
mis-computes the background reported by xterm?  That is, it sets up
for a dark background when it is in fact light?  Or is the background
mode computed correctly, but the call to tty-set-up-initial-frame-faces
in its new location does not do what it's expected to do?

If the latter, then I'd step through tty-set-up-initial-frame-faces to
see what goes wrong there.  I see that it calls
frame-set-background-mode, so perhaps the problem is within that
function.

(Sorry, I don't have access to an xterm to try all this myself.)

Re: colours in client on xterm (if an X frame is open at same time)

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Date: Fri, 8 Jan 2010 20:18:58 -0800 (PST)
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Cc: emacs-devel@gnu.org
  > > 
  > >   > In your case the only effect that patch should have is to move the call
  > >   >  (tty-set-up-initial-frame-faces) from before
  > >   > 
  > >   > (let ((coding-system-for-read 'binary)
  > >   > 
  > >   > to after it.
  > >  
  > > If I put back the `tty-set-up-initial-frame-faces' call (after
  > > `xterm-register-default-colors') and make current
  > > `tty-set-up-initial-frame-faces' conditional on detecting a dark
  > > background, then everything seems to work OK.  
  > > 
  > > Calling `tty-set-up-initial-frame-faces' twice in the dark background
  > > case is very ugly, but in case nobody finds a better solution soon I'll
  > > check in that change soon.
  > 
  > I wasn't following this thread.  I don't know if I can help, but
  > there's something I don't understand: is it the case that the new code
  > mis-computes the background reported by xterm?  That is, it sets up
  > for a dark background when it is in fact light? 

No, the background mode is computed just fine, and it's light (the
default for xterm anyway).

  >  Or is the background mode computed correctly, but the call to
  > tty-set-up-initial-frame-faces in its new location does not do what
  > it's expected to do?
  > 
  > If the latter, then I'd step through tty-set-up-initial-frame-faces to
  > see what goes wrong there.  I see that it calls
  > frame-set-background-mode, so perhaps the problem is within that
  > function.

In the case where everything works correctly (before the patch),
when stepping through frame-set-background-mode (called by
tty-set-up-initial-frame-faces) the default face gets set up wrong.
So debugging hurts in this case :-(

Re: colours in client on xterm (if an X frame is open at same time)

[Eli Zaretskii]

> Date: Sun, 10 Jan 2010 00:49:53 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: ulm@gentoo.org, emacs-devel@gnu.org
> 
> In the case where everything works correctly (before the patch),
> when stepping through frame-set-background-mode (called by
> tty-set-up-initial-frame-faces) the default face gets set up wrong.
> So debugging hurts in this case :-(

Sorry, I'm not sure I understand: does it mean that stepping through
frame-set-background-mode changes the result? that is, it works
differently under a debugger than it does normally?

Re: colours in client on xterm (if an X frame is open at same time)

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Date: Sun, 10 Jan 2010 00:49:53 -0800 (PST)
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Cc: ulm@gentoo.org, emacs-devel@gnu.org
  > > 
  > > In the case where everything works correctly (before the patch),
  > > when stepping through frame-set-background-mode (called by
  > > tty-set-up-initial-frame-faces) the default face gets set up wrong.
  > > So debugging hurts in this case :-(
  > 
  > Sorry, I'm not sure I understand: does it mean that stepping through
  > frame-set-background-mode changes the result? that is, it works
  > differently under a debugger than it does normally?

Exactly.