From xemacs-m  Sun Mar 23 20:35:08 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id UAA10574
	for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 20:35:07 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQcies26747; Sun, 23 Mar 1997 21:35:08 -0500 (EST)
Date: Sun, 23 Mar 1997 21:35:08 -0500 (EST)
Message-Id: <QQcies26747.199703240235@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: patches to compile.el
In-Reply-To: <rvend6xf9t.fsf@sdnp5.ucsd.edu>
References: <199703230329.WAA05074@pochacco.alphatech.com>
	<m267yimdxs.fsf@altair.xemacs.org>
	<rvohcaxkt7.fsf@sdnp5.ucsd.edu>
	<QQcieg24048.199703232340@crystal.WonderWorks.COM>
	<rvlo7exhz9.fsf@sdnp5.ucsd.edu>
	<QQciel25192.199703240057@crystal.WonderWorks.COM>
	<rvend6xf9t.fsf@sdnp5.ucsd.edu>
X-Mailer: VM 6.23 under 19.15 XEmacs Lucid (beta103)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

David Moore writes:
 > Kyle Jones <kyle_jones@wonderworks.com> writes:
 > 
 > > With luck we can someday make minibuffers work the way Dog
 > > intended and have a different one per frame.  FSF Emacs is part
 > > way there, but it still partially stacks them and has some
 > > display problems.
 > 
 > I think he also intended emacs to be multithreaded, and I'm not too sure
 > how you really make multiple minibuffers work w/o that.

?

What does multithreading have to do with it?  It's just different
buffers in different windows on different frames.  What else do you
need other than some hacking to make the minibuffer stacking be
frame local?

 > I think we've now reached the realm of discussing XEmacs
 > 21. :) I would suspect the thing to do would be to have the
 > minibuffer-prompt function do now what it does currently.
 > When we get to the days of multiple simultaneous minibuffers,
 > that function would change to take an optional arg of which
 > minibuffer to use, with the default being the most recent one
 > or the one on the current frame or the one in the environment
 > closure which is also defining `current-buffer' for this
 > thread or whatever other default seemed reasonable at the
 > time.

Or just leave it commented out and not worry about all this.  Which
was my point.

