From xemacs-m  Fri Feb 28 23:49:47 1997
Received: from corona.pixar.com (corona.pixar.com [138.72.20.84])
	by xemacs.org (8.8.5/8.8.5) with SMTP id XAA17825
	for <xemacs-beta@xemacs.org>; Fri, 28 Feb 1997 23:49:46 -0600 (CST)
Received: by corona.pixar.com (Smail3.1.29.1 #2)
	id m0w0gvY-0001YDC; Fri, 28 Feb 97 21:01 PST
Sender: retnuh@pixar.com (Hunter Kelly)
Sender: retnuh@corona
To: Hunter Kelly <retnuh@corona.pixar.com>
Cc: xemacs-beta@xemacs.org
Subject: RFC:  pre-display-buffer-function [was Re: annoying buffer switching/focus  behavior]
References: <yvtafoo8frj.fsf@corona.pixar.com>
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
From: Hunter Kelly <retnuh@corona.pixar.com>
Date: 28 Feb 1997 21:01:43 -0800
In-Reply-To: Hunter Kelly's message of 28 Feb 1997 19:14:56 -0800
Message-ID: <yvt91488atk.fsf@corona.pixar.com>
Lines: 95
X-Mailer: Gnus v5.4.11/XEmacs 19.15

A follow up to my previous report (feeling like a lazy bastard for not
tracking down the bug myself):

It looks like the problem is this:
list-buffers (and grep, and tons of other things) call display-buffer.
display-buffer in turn runs pre-display-buffer-function, which by
default is get-frame-for-buffer, which in turn calls
get-frame-for-buffer-noselect.

At the end of get-frame-for-buffer-noselect is the following:


     (t
      ;;
      ;; This buffer's mode did not express a preference for a frame of a
      ;; particular name.  So try to find a frame already displaying this
      ;; buffer.  
      ;;
      (let ((w (or (get-buffer-window buffer 'visible)	; check visible first
		   (get-buffer-window buffer 0))))	; then iconic
	(cond ((null w)
	       ;; It's not in any window - return nil, meaning no frame has
	       ;; preference.
	       nil)
	      ((and not-this-window-p
		    (eq (selected-frame) (window-frame w)))
	       ;; It's in a window, but on this frame, and we have been
	       ;; asked to pick another window.  Return nil, meaning no
	       ;; frame has preference.
	       nil)
	      (t
	       ;; Otherwise, return the frame of the buffer's window.
	       (window-frame w))))))))


So this means if a buffer is already in a frame, that is not the
selected frame, display-buffer, by default, will try and select the
other frame.  I guess setting pre-display-buffer-function to nil will
help those who don't like it, but is this desireable default behavior?
I'm an experienced user, and _I_ find it confusing and annoying.  I
think it would bother a novice even more.

We could add a customization variable, or change the value of the hook
(which I don't think is the right thing, it seems like
get-frame-for-buffer does useful things), or change what happens in
the case I illustrated above.  I'll do the work, I just need a
consensus on what the right thing is.

Anyone?

Hunter

Hunter Kelly <retnuh@corona.pixar.com> writes:

> I've seen this behavior in many of the XEmacs 19.15 betas.  I thought
> it went away around 90 or so, but it is here in 92 (I know, I have had
> a ton of work...).
> 
> The annoyance is this:
> 
> xemacs -q
> 
> C-x 5 b a RET
> 
> C-x 5 b b RET
> 
> In the most recent frame, type C-x C-b
> Then, switch to another frame, and type C-x C-b
> 
> The frame does not show up.  Major annoying.
> 
> I think the same problem can be shown another way:
> 
> xemacs -q
> 
> C-x 5 b a RET
> C-x 5 b b RET
> 
> M-x grep host /etc/hosts
> 
> Switch to another frame, and
> M-x grep spoo /etc/hosts
> 
> XEmacs throws the focus to the frame with the first grep in it.
> 
> What I want is for XEmacs to display the buffer in the current frame,
> regardless of whether it is currently displayed or not, and not
> randomly throw the focus around.  This seems to happen whether or not
> 'focus-follows-mouse' is t or nil.
> 
> I think this behavior is wrong.  It shouldn't have anything to do with
> the focus model when it is fixed, either.
> 
> Hunter, who has like 9 frames laying around and doesn't want to have
> to find the one with a particular buffer in it to see it, dangit.

