From xemacs-m  Wed Jan  8 12:42:45 1997
Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with ESMTP
	  id MAA11291 for <xemacs-beta@xemacs.org>; Wed, 8 Jan 1997 12:42:44 -0600 (CST)
Received: from kiki.icd.teradyne.com (kiki.icd.teradyne.com [131.101.1.30]) by steadfast.teradyne.com (8.7.1/8.7.1) with ESMTP id NAA14218 for <xemacs-beta@xemacs.org>; Wed, 8 Jan 1997 13:45:33 -0500 (EST)
Received: from spacely.icd.teradyne.com (spacely.icd.teradyne.com [131.101.10.9]) by kiki.icd.teradyne.com (8.7.1/8.7.1) with SMTP id NAA28489 for <xemacs-beta@xemacs.org>; Wed, 8 Jan 1997 13:40:01 -0500 (EST)
Received: from spacely by spacely.icd.teradyne.com (SMI-8.6/SMI-SVR4)
	id NAA25259; Wed, 8 Jan 1997 13:42:14 -0500
Message-Id: <199701081842.NAA25259@spacely.icd.teradyne.com>
X-Mailer: exmh version 2.0beta (patched 1/7/97)
To: xemacs-beta@xemacs.org
reply-to: acs@acm.org
Subject: Setting default-frame-plist
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 08 Jan 1997 13:42:13 -0500
From: Vinnie Shelton  <shelton@icd.teradyne.com>

I'm trying to figure out how to set default-frame-plist during emacs 
startup without changing the initial frame.  As I was composing this email 
message, it occurred to me that I should:

1) Set initial-frame-plist to the properties I want the initial frame to 
have, and then
2) Set default-frame-plist to the properties I want subsequent frames to 
have.

This largely works, *except for the minibuffer property*.  If I want the 
initial frame to have a minibuffer, I add the property '(minibuffer t) to 
the initial-frame-plist.  This gives me an error, because the frame already 
has a minibuffer.  If I add the property '(minibuffer nil) to the 
default-frame-plist and don't add the property '(minibuffer t) to the 
initial-frame-plist, I get a new minibuffer-only frame.

How can I set my startup stuff up so that I make one frame with a minibuffer
and make all other frames without a minibuffer?

BTW, this behavior seems to be consistent among 19.14, 19.15 and 20.0.

--vin

