From xemacs-m  Tue May  6 13:32:13 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 NAA12565
	for <xemacs-beta@xemacs.org>; Tue, 6 May 1997 13:32:09 -0500 (CDT)
Received: by crystal.WonderWorks.COM 
	id QQcojy28149; Tue, 6 May 1997 14:32:11 -0400 (EDT)
Date: Tue, 6 May 1997 14:32:11 -0400 (EDT)
Message-Id: <QQcojy28149.199705061832@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 Developers <xemacs-beta@xemacs.org>
Subject: Re: Minibuffer and  multiple frames
In-Reply-To: <kig911s4g7w.fsf@jagor.srce.hr>
References: <16594.862938741@rtp.ericsson.se>
	<kigd8r44hsz.fsf@jagor.srce.hr>
	<QQcojw27788.199705061805@crystal.WonderWorks.COM>
	<kig911s4g7w.fsf@jagor.srce.hr>
X-Mailer: VM 6.31 under 20.2 XEmacs Lucid (beta4)
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

Hrvoje Niksic writes:
 > Kyle Jones <kyle_jones@wonderworks.com> writes:
 > 
 > > Hrvoje Niksic writes:
 > >  > It's definitely annoying.  We should implement the
 > >  > minibuffer-per-frame stuff correctly.  However, I don't have an
 > >  > estimate of the amount of work it would take.
 > > 
 > > A while ago David Moore pointed out that this basically means
 > > implementing threading.
 > 
 > Uh, yes.  But I don't remember his exact arguments.  David, could you
 > remind us what was wrong with the minibuffer-per-frame model?

The gist of it is that a minibuffer read is currently a recursive
edit.  Everything from then until the minibuffer erad completes
is run inside that new context.  If you did another minibuffer
read and then wanted to get back to the previous minibuffer read,
the all contexts above it would have to be popped off the stack
unless you had threaded execution.

The only way around it that I see is to get rid of the recurisve edit
aspect of minibuffer reads, which means no recurisve minibuffers.
This isn't such a bad trade if you get a separate minibuffer per frame.

