* colours in client on xterm (if an X frame is open at same time)
@ 2010-01-07 23:26 Ulrich Mueller
2010-01-07 23:58 ` Dan Nicolaescu
2010-01-08 3:02 ` Eric Hanchrow
0 siblings, 2 replies; 14+ messages in thread
From: Ulrich Mueller @ 2010-01-07 23:26 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-07 23:26 colours in client on xterm (if an X frame is open at same time) Ulrich Mueller
@ 2010-01-07 23:58 ` Dan Nicolaescu
2010-01-08 6:43 ` Ulrich Mueller
2010-01-08 3:02 ` Eric Hanchrow
1 sibling, 1 reply; 14+ messages in thread
From: Dan Nicolaescu @ 2010-01-07 23:58 UTC (permalink / raw
To: Ulrich Mueller; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-07 23:26 colours in client on xterm (if an X frame is open at same time) Ulrich Mueller
2010-01-07 23:58 ` Dan Nicolaescu
@ 2010-01-08 3:02 ` Eric Hanchrow
1 sibling, 0 replies; 14+ messages in thread
From: Eric Hanchrow @ 2010-01-08 3:02 UTC (permalink / raw
To: Ulrich Mueller; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-07 23:58 ` Dan Nicolaescu
@ 2010-01-08 6:43 ` Ulrich Mueller
2010-01-08 7:13 ` Dan Nicolaescu
2010-01-08 7:47 ` Jan Djärv
0 siblings, 2 replies; 14+ messages in thread
From: Ulrich Mueller @ 2010-01-08 6:43 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-08 6:43 ` Ulrich Mueller
@ 2010-01-08 7:13 ` Dan Nicolaescu
2010-01-08 16:29 ` Ulrich Mueller
2010-01-08 7:47 ` Jan Djärv
1 sibling, 1 reply; 14+ messages in thread
From: Dan Nicolaescu @ 2010-01-08 7:13 UTC (permalink / raw
To: Ulrich Mueller; +Cc: emacs-devel
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...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-08 6:43 ` Ulrich Mueller
2010-01-08 7:13 ` Dan Nicolaescu
@ 2010-01-08 7:47 ` Jan Djärv
2010-01-08 16:48 ` Dan Nicolaescu
1 sibling, 1 reply; 14+ messages in thread
From: Jan Djärv @ 2010-01-08 7:47 UTC (permalink / raw
To: Ulrich Mueller; +Cc: Dan Nicolaescu, emacs-devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-08 7:13 ` Dan Nicolaescu
@ 2010-01-08 16:29 ` Ulrich Mueller
2010-01-08 18:28 ` Dan Nicolaescu
0 siblings, 1 reply; 14+ messages in thread
From: Ulrich Mueller @ 2010-01-08 16:29 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-08 7:47 ` Jan Djärv
@ 2010-01-08 16:48 ` Dan Nicolaescu
0 siblings, 0 replies; 14+ messages in thread
From: Dan Nicolaescu @ 2010-01-08 16:48 UTC (permalink / raw
To: Jan Djärv; +Cc: Ulrich Mueller, emacs-devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-08 16:29 ` Ulrich Mueller
@ 2010-01-08 18:28 ` Dan Nicolaescu
2010-01-08 22:31 ` Ulrich Mueller
[not found] ` <201001090418.o094Iw6d007997@godzilla.ics.uci.edu>
0 siblings, 2 replies; 14+ messages in thread
From: Dan Nicolaescu @ 2010-01-08 18:28 UTC (permalink / raw
To: Ulrich Mueller; +Cc: emacs-devel
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...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-08 18:28 ` Dan Nicolaescu
@ 2010-01-08 22:31 ` Ulrich Mueller
[not found] ` <201001090418.o094Iw6d007997@godzilla.ics.uci.edu>
1 sibling, 0 replies; 14+ messages in thread
From: Ulrich Mueller @ 2010-01-08 22:31 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: emacs-devel
>>>>> 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...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
[not found] ` <201001090418.o094Iw6d007997@godzilla.ics.uci.edu>
@ 2010-01-09 7:55 ` Eli Zaretskii
2010-01-10 8:49 ` Dan Nicolaescu
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2010-01-09 7:55 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: ulm, emacs-devel
> 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.)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-09 7:55 ` Eli Zaretskii
@ 2010-01-10 8:49 ` Dan Nicolaescu
2010-01-10 18:03 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Dan Nicolaescu @ 2010-01-10 8:49 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ulm, emacs-devel
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 :-(
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-10 8:49 ` Dan Nicolaescu
@ 2010-01-10 18:03 ` Eli Zaretskii
2010-01-10 18:32 ` Dan Nicolaescu
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2010-01-10 18:03 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: ulm, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: colours in client on xterm (if an X frame is open at same time)
2010-01-10 18:03 ` Eli Zaretskii
@ 2010-01-10 18:32 ` Dan Nicolaescu
0 siblings, 0 replies; 14+ messages in thread
From: Dan Nicolaescu @ 2010-01-10 18:32 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ulm, emacs-devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-01-10 18:32 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-07 23:26 colours in client on xterm (if an X frame is open at same time) Ulrich Mueller
2010-01-07 23:58 ` Dan Nicolaescu
2010-01-08 6:43 ` Ulrich Mueller
2010-01-08 7:13 ` Dan Nicolaescu
2010-01-08 16:29 ` Ulrich Mueller
2010-01-08 18:28 ` Dan Nicolaescu
2010-01-08 22:31 ` Ulrich Mueller
[not found] ` <201001090418.o094Iw6d007997@godzilla.ics.uci.edu>
2010-01-09 7:55 ` Eli Zaretskii
2010-01-10 8:49 ` Dan Nicolaescu
2010-01-10 18:03 ` Eli Zaretskii
2010-01-10 18:32 ` Dan Nicolaescu
2010-01-08 7:47 ` Jan Djärv
2010-01-08 16:48 ` Dan Nicolaescu
2010-01-08 3:02 ` Eric Hanchrow
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.