[simon.marshall@misys.com: font frame property oddities]

[simon.marshall@misys.com: font frame property oddities]

[Richard Stallman]

------- Start of forwarded message -------
From: "Marshall, Simon" <simon.marshall@misys.com>
To: "'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'"
	<emacs-pretest-bug@gnu.org>
Date: Thu, 22 Jun 2006 10:24:05 +0100
MIME-Version: 1.0
Content-Type: text/plain
Subject: font frame property oddities
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

This is from CVS as of 2006-06-19.  Try:

xrdb -load
^D
src/emacs -Q
(make-frame '((font . "6x10"))) C-x C-e
(make-frame '((font . "10x20"))) C-x C-e

This pops up 2 frames with the correct font.  Now try:

src/emacs -Q --font=9x15
(make-frame '((font . "6x10"))) C-x C-e
(make-frame '((font . "10x20"))) C-x C-e

This time, both new frames have the default font (9x15).  The same applies
if you use the "Emacs*font" resource rather than the "--font" flag. 

Set-frame-font does change the font in the frame though.

I found this passage in "File: elisp,  Node: Color Parameters":
"These frame parameters are semi-obsolete in that they are
automatically equivalent to particular face attributes of particular
faces.

`font'
     The name of the font for displaying text in the frame.  This is a
     string, either a valid font name for your system or the name of an
     Emacs fontset (*note Fontsets::).  It is equivalent to the `font'
     attribute of the `default' face."

I'm not sure what is meant by semi-obsolete.  Are we no longer supposed to
use them?  The info node doesn't say what we should do instead.  Certainly,
foreground-color still works.

So, I think there is a bug: the font frame parameter is being ignored if a
default font is specified either on the command line or by an X resource.

In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit)
 of 2006-06-19 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure '--with-x-toolkit=lucid' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_GB.ISO8859-1
  value of $LC_CTYPE: en_GB.ISO8859-1
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: en_GB.ISO8859-1
  value of $LC_NUMERIC: en_GB.ISO8859-1
  value of $LC_TIME: en_GB.ISO8859-1
  value of $LANG: en_GB.ISO8859-1
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [simon.marshall@misys.com: font frame property oddities]

[Chong Yidong]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Subject: font frame property oddities

> src/emacs -Q --font=9x15
> (make-frame '((font . "6x10"))) C-x C-e
> (make-frame '((font . "10x20"))) C-x C-e
>
> both new frames have the default font (9x15).  The same applies
> if you use the "Emacs*font" resource rather than the "--font" flag. 

I fixed this.  It also fixes an old overlooked bug from February:

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 18 Feb 2006 08:44:47 -0500
> Subject: Funny handling of font for initial minibuffer-only
> 	frame (was: Funny handling of background color for initial
> 	minibuffer-only frame)
>
>    emacs -Q --eval "(setq initial-frame-alist
>                           '((minibuffer . only)
>                             (font .
>    \"-misc-fixed-bold-r-normal-*-24-*-*-*-*-*-*-*\")))"
>
> You'll notice that the (minibuffer-only) frame uses the default font rather
> than the -misc-fixed-bold-r-normal-*-24-*-*-*-*-*-*-* specified.
> This worked until around mid-january (the problem appeared at the same time
> as the background-color problem above, AFAICT).

Re: [simon.marshall@misys.com: font frame property oddities]

[Stefan Monnier]

> I fixed this.  It also fixes an old overlooked bug from February:

>> Subject: Funny handling of font for initial minibuffer-only
>> frame (was: Funny handling of background color for initial
>> minibuffer-only frame)

Indeed, it does.  Thank you very much,


        Stefan "happily seeing his minibuffer font back to normal"