GNU bug report logs - #47
23.0.60; 'default' face not set properly in new frame

Previous Next

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

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Tim Van Holder <tim.vanholder <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; 'default' face not set properly in new frame
Date: Fri, 07 Mar 2008 13:34:03 +0100

In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2008-03-07 on leeloo
Windowing system distributor `RealVNC Ltd', version 11.0.3370
configured using `configure  '--with-x-toolkit=gtk' '--with-x' '--with-freetype' '--with-xft' '--with-libotf''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

While in an ediff-buffers session, I executed M-x make-frame to get a new
window. That newly created window did not have the correct font set (it
used Adobe Courier while I have the default face customized to use the
Terminus font).
M-x customize-face default showed it as "SAVED and set" with courier as
the font family. "Reset to saved settings" caused both frames to be
repainted, using the correct font.
Another M-x make-frame once again used the wrong font, so it seems
something goes wrong during frame creation causing new frames to get an
incorrectly set default face.

Message #14 received at 47 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "James Aguilar" <aguilar.james <at> gmail.com>
To: 47 <at> debbugs.gnu.org
Date: Mon, 16 Jun 2008 15:18:40 -0700

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

I was able to get around this bug by specifying the following in my
.Xdefaults file:

Emacs.FontBackend: xft
Emacs.font: Consolas-7.5

Then doing xrdb -load .Xdefaults.

(Beware, xrdb seems to silently discard the last line of the file if you
don't terminate it with a newline.)

This gets me the desired behavior on new frames.  Emacs is the only program
out of the half dozen I regularly use that was unable to specify its own
font.  In fact, it is the only program I have _ever_ used that falls into
that set.  I'm sure there are very good explanations and/or historical
reasons for this, but it's a serious pain point.

Another data point: I originally observed this problem on an emacs matching
with the following version string:

GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2008-06-16

This is the emacs I checked out from CVS yesterday.

I have another emacs with the following version string:

GNU Emacs 23.0.60.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.8.20) of
2008-05-15

If I use this emacs on my desktop workstation, I have no issues with new
frames and fonts.  But if I use the same source, compile it, and load it on
my laptop (the same machine on which I originally encountered the bug), I
have the bug.  This convinces me that there is some interaction between
emacs and my computer that is present on one machine but absent on the other
that is causing this issue.

I've checked xrdb and there's nothing to explain the problem there.  I have
no manually set fonts in either except when my workaround is active.  I
don't know where else to look, but I do have two machines to diff if you
guys have some suggestions or things you would like me to copy.

-- James

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

Message #19 received at 47 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 47 <at> debbugs.gnu.org
Subject: Re: 'default' face not set properly in new frame 
Date: Wed, 18 Jun 2008 21:59:43 -0400

I've made some changes (in the trunk) to the way the default face and
the `font' frame-parameter are handled.  This should fix the problem
where changes to the default face applied via Custom did not apply to
new frames.  Please test and report if you still see the problem,


        Stefan

Message #24 received at 47 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Tim Van Holder <tim.vanholder <at> gmail.com>
To: 47 <at> debbugs.gnu.org
Subject: Font is correct, but potential bad side effect
Date: Mon, 23 Jun 2008 11:33:10 +0200

The font in a new frame (via C-x 5 2) is now correct.
I do see a new problem though (first noticed it last Friday): I have a
width & height specified in default-frame-alist (132x60), and that no
longer gets applied when I start emacs (the exact size I get seems to be
somewhat nondeterministic - I've gotten 132x57, 126x55, 116x52, ...).
Is the size perhaps being computed with the courier font and then not 
getting updated with the new default font?

Side note: I did not get an email from the bugtracker when Stefan added
that status update, which I assume is a bug in the bugtracker
configuration...

Message #29 received at 47 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Tim Van Holder" <tim.vanholder <at> gmail.com>
To: 47 <at> debbugs.gnu.org
Subject: Re: bug#47 closed by Chong Yidong <cyd <at> stupidchicken.com> (Re: 23.0.60; Default face in new frames)
Date: Wed, 23 Jul 2008 09:25:20 +0200

> From: Chong Yidong <cyd <at> stupidchicken.com>
> To: 120-done <at> emacsbugs.donarmstrong.com
> Date: Wed, 23 Jul 2008 01:22:05 -0400
> Subject: Re: 23.0.60; Default face in new frames
> I believe this is now fixed in the trunk.

While this is true for the originally reported issue, that is not
the case for the frame size issue I reported on bug #47.
But I'll add a new, separate bug for that - it was never certain
that it was caused by the fix for #47.

Previous Next

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