GNU bug report logs - #10748
colours in client on xterm (if an X frame is open at same time)

Previous Next

Package: emacs;

Reported by: sam <garen <at> tychoish.com>

Date: Tue, 7 Feb 2012 05:03:01 UTC

Severity: normal

Merged with 10905

Found in version 24.0.94

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10748 in the body.
You can then email your comments to 10748 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#10748; Package emacs. (Tue, 07 Feb 2012 05:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to sam <garen <at> tychoish.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 07 Feb 2012 05:03:02 GMT) Full text and rfc822 format available.

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

From: sam <garen <at> tychoish.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: colours in client on xterm (if an X frame is open at same time)
Date: Mon, 6 Feb 2012 23:48:45 -0500
[Message part 1 (text/plain, inline)]
http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00454.html

I've not been able to find record of this bug anywhere, and no one in
#emacs seemed to have any sense of this bug. My research. I (first)
experienced this bug had this bug in a build from the bzr trunk with the
Lucid toolkit.

(See the following blog post to describe why I'm using lucid rather than
GTK: http://tychoish.com/rhizome/persistent-emacs-daemons/)

I'm willing to provide a copy of my package or whatever you require.

Cheers,
sam

> On Mon, Feb 6, 2012 at 3:29 PM, Sam Kleinman <sam <at> tychoish.com> wrote:
> >
> >> 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.
> >
> >
> > Hello,
> >
> > I just ran across this exact problem for the first time in a new
> > emacs-lucid-bzr build, and I have no clue what happened to cause it or
> > what my configuration is causing this.
> >
> > Are you still having this problem? What have you done to work around
> > this? Is this something that I should reopen a thread on some mailing
> > list?

On Mon, Feb 06, 2012 at 06:15:58PM -0800, Eric Hanchrow wrote:
> I no longer use "emacsclient --tty", so I haven't had the opportunity
> to see this.

> >
> > Cheers,
> > sam
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10748; Package emacs. (Mon, 27 Feb 2012 22:15:01 GMT) Full text and rfc822 format available.

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

From: Oleksandr Manzyuk <manzyuk <at> gmail.com>
To: 10748 <at> debbugs.gnu.org
Date: Mon, 27 Feb 2012 22:10:33 +0000
I'd like to confirm this problem.  I've chased it down to the function
`face-spec-reset-face' from lisp/faces.el.  The version from Emacs
23.2:

(defun face-spec-reset-face (face &optional frame)
  "Reset all attributes of FACE on FRAME to unspecified."
  (let ((attrs face-attribute-name-alist))
    (while attrs
      (let ((attr-and-name (car attrs)))
	(set-face-attribute face frame (car attr-and-name) 'unspecified))
      (setq attrs (cdr attrs)))))

The same function from trunk:

(defun face-spec-reset-face (face &optional frame)
  "Reset all attributes of FACE on FRAME to unspecified."
  (unless (eq face 'default)
    (let (reset-args)
      (dolist (attr-and-name face-attribute-name-alist)
	(push 'unspecified reset-args)
	(push (car attr-and-name) reset-args))
      (apply 'set-face-attribute face frame reset-args))))

Why does the latter not reset the default face?  If I start Emacs with
"emacs -Q", start the server with M-x server-start, and evaluate the
former definition in the *scratch* buffer, then doing "emacsclient -t"
from the terminal gives me a frame that respects my terminal
background color.

Best,
Sasha
-- 
Oleksandr Manzyuk
http://oleksandrmanzyuk.wordpress.com




Merged 10748 10905. Request was from Juanma Barranquero <lekktu <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 28 Feb 2012 12:30:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10748; Package emacs. (Tue, 28 Feb 2012 14:35:02 GMT) Full text and rfc822 format available.

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

From: Oleksandr Manzyuk <manzyuk <at> gmail.com>
To: 10748 <10748 <at> debbugs.gnu.org>
Subject: Ping
Date: Tue, 28 Feb 2012 14:30:20 +0000
To save you reading the thread linked in the original bug report, here
is how to reproduce the bug:

1. emacs -Q
2. M-x server-start
3. Open a terminal with nonstandard foreground and/or background colors.
   For the sake of example, I assume that you've run "xterm -bg yellow".
4. Run "emacsclient -t" in the terminal.

The observed behavior: the background becomes grey, whereas the expected
behavior is that Emacs honors the terminal background color (yellow).

I normally set the background to white in .Xresources.  I've used yellow
color only to make my point.

This behavior is a regression in Emacs 24.  I've chased it down to this
commit:

commit 27528399fd429b2f510e13f361affb1e2211ceb3
Author: Chong Yidong <cyd <at> gnu.org>
Date:   Tue Jan 31 16:38:58 2012 +0800

   Fix menu-set-font interaction with Custom themes.

   In particular, prevent it from setting non-font-related attributes
   like the foreground and background color.  This requires a bugfix to
   face-spec-reset-face to make "resetting" the default face work.

   * lisp/faces.el (face-spec-reset-face): Don't apply unspecified
   attribute values to the default face.

   * lisp/frame.el (set-frame-font): New arg ALL-FRAMES.

   * lisp/menu-bar.el (menu-set-font): Use set-frame-font.

`face-spec-reset-face' has been changed to reset only non-default faces.
While I understand the rationale of this change, it seems to break
handling of fore- and background colors in terminal.  If I evaluate the
old definition of `face-spec-reset-face' in the *scratch* buffer,
connecting to Emacs with "emacsclient -t" works the way I am used to.
-- 
Oleksandr Manzyuk
http://oleksandrmanzyuk.wordpress.com




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10748; Package emacs. (Sun, 04 Mar 2012 15:08:02 GMT) Full text and rfc822 format available.

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

From: Chong Yidong <cyd <at> gnu.org>
To: sam <garen <at> tychoish.com>
Cc: Oleksandr Manzyuk <manzyuk <at> gmail.com>, 10748 <at> debbugs.gnu.org
Subject: Re: bug#10748: colours in client on xterm (if an X frame is open at
	same time)
Date: Sun, 04 Mar 2012 23:06:23 +0800
> 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.

I've committed a fix for this bug to the trunk.  Thanks.




bug closed, send any further explanations to 10748 <at> debbugs.gnu.org and sam <garen <at> tychoish.com> Request was from Chong Yidong <cyd <at> gnu.org> to control <at> debbugs.gnu.org. (Wed, 20 Jun 2012 15:32:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 19 Jul 2012 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 11 years and 307 days ago.

Previous Next


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