From xemacs-m  Sun Mar 23 19:12:29 1997
Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id TAA09915
	for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 19:12:28 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id RAA26622 for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 17:12:29 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id RAA05200; Sun, 23 Mar 1997 17:14:22 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: XEmacs Beta Mailing List <xemacs-beta@xemacs.org>
Subject: Re: patches to compile.el
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>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: David Moore <dmoore@ucsd.edu>
Date: 23 Mar 1997 17:14:22 -0800
In-Reply-To: Kyle Jones's message of Sun, 23 Mar 1997 19:57:41 -0500 (EST)
Message-ID: <rvend6xf9t.fsf@sdnp5.ucsd.edu>
Lines: 18
X-Mailer: Gnus v5.4.33/XEmacs 19.15(beta103)

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.

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.

