From xemacs-m  Wed Feb 12 09:56:06 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 JAA29414
	for <xemacs-beta@xemacs.org>; Wed, 12 Feb 1997 09:56:04 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQccpb09057; Wed, 12 Feb 1997 10:56:02 -0500 (EST)
Date: Wed, 12 Feb 1997 10:56:02 -0500 (EST)
Message-Id: <QQccpb09057.199702121556@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@xemacs.org
Subject: 20.0: changing frame ordering improves selection behavior

Create three frames in succession, F1, F2, F3.  Under XEmacs the
frame list looks like this

(F1 F2 F3)

Under FSF Emacs it looks like this

(F3 F2 F1)

Now delete the selected frame, which is F3.  FSF Emacs selects
F2, since F2 is after F3 in its list.  XEmacs selects F1, since
F3 has no next in its list.  F1 is probably at the bottom of the
window system's frame stack since it was created first.  So if
XEmacs Lisp code deletes a frame and then does a minibuffer read,
the minibuffer window chosen is in F1, at the bottom of the
frame stack.  FSF Emacs running the same code uses the minibuffer
window of F2 which is at the top of the frame stack.

FSF Emacs' default behavior in this case is better.  If I change
XEmacs code to build the frame list like FSF Emacs does, it's
behavior similarly improves.

Here is the patch against 20.0:

*** 1.1 1997/02/12 15:31:30
--- src/frame.c     1997/02/12 15:33:11
***************
*** 460,466 ****
--- 460,469 ----
       the frame-specific version of the buffer-alist unless the frame
       is accessible from the device. */
  
+ #if 0
    DEVICE_FRAME_LIST (d) = nconc2 (DEVICE_FRAME_LIST (d), Fcons (frame, Qnil));
+ #endif
+   DEVICE_FRAME_LIST (d) = Fcons (frame, DEVICE_FRAME_LIST (d));
    RESET_CHANGED_SET_FLAGS;
  
    /* Now make sure that the initial cached values are set correctly.

