From xemacs-m  Sun Mar 23 20:54:00 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 UAA11867
	for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 20:53:58 -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 SAA00301 for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 18:53:58 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id SAA05430; Sun, 23 Mar 1997 18:55:52 -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> 	<rvend6xf9t.fsf@sdnp5.ucsd.edu> <QQcies26747.199703240235@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 18:55:51 -0800
In-Reply-To: Kyle Jones's message of Sun, 23 Mar 1997 21:35:08 -0500 (EST)
Message-ID: <rvbu8axako.fsf@sdnp5.ucsd.edu>
Lines: 46
X-Mailer: Gnus v5.4.33/XEmacs 19.15(beta103)

Kyle Jones <kyle_jones@wonderworks.com> writes:

> 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?

Operations which use the minibuffer are "blocking" operations from the
point of view of lisp functions which call them.

So if I have

(defun foo ()
  (when (yes-or-no-p "Edit your mail? ")
     ...))

And

(defun bar ()
  (let ((x (completing-read "Insert which C function: " my-c-table)))
    (insert x)))


If in one window I press a key to run `foo', and then switch to another
frame and run `bar'.  Even if I could get the minibuffer associated with
foo, pressing yesRET will do no good, because the only way for that
function to continue would be for it to be in a different thread than
bar.  You'd need a way to allow foo to continue while still blocking
bar.  And that requires support for multiple lisp threads.


So, yeah, you could have multiple simultaneous minibuffers, but their
code could only proceed once you've cleared any minibuffer operations
which followed them, making it fairly useless.  As it is now, the user
at least realizes that they have to answer the most recent one before an
older one can continue.  Principle of least surprise.


Also, I'm not particularly advocating support for multiple lisp level
threads.  It'd be a bit of a nightmare with the current lisp engine.  If
you had something with first-order environment closures and
continuations like scheme, it'd be a lot simpler.

It's just that you can't return from blocking operations out-of-order
unless you have language level support for such things.  Which I don't
think we're even close to having.

