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

[Dan Nicolaescu <dann@ics.uci.edu>]

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