From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: display-buffer-other-frame - useful? doc string? Date: Mon, 07 Apr 2008 12:01:26 -0400 Message-ID: References: <002401c8820f$7d6042c0$0600a8c0@us.oracle.com> <000001c8977b$146abc10$0200a8c0@us.oracle.com> <000001c897bb$26e5ebe0$0200a8c0@us.oracle.com> <001901c8984d$5a62fe80$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207584552 22478 80.91.229.12 (7 Apr 2008 16:09:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Apr 2008 16:09:12 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 07 18:09:45 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JituF-0001mB-6E for ged-emacs-devel@m.gmane.org; Mon, 07 Apr 2008 18:09:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jittb-0000mG-UV for ged-emacs-devel@m.gmane.org; Mon, 07 Apr 2008 12:08:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JitnD-0001iL-6q for emacs-devel@gnu.org; Mon, 07 Apr 2008 12:01:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JitnC-0001hO-4N for emacs-devel@gnu.org; Mon, 07 Apr 2008 12:01:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JitnA-0001gs-Db for emacs-devel@gnu.org; Mon, 07 Apr 2008 12:01:56 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jitn9-0002Ue-VR for emacs-devel@gnu.org; Mon, 07 Apr 2008 12:01:56 -0400 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1Jitn9-0000El-Lz for emacs-pretest-bug@gnu.org; Mon, 07 Apr 2008 12:01:55 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Jitn4-0002Ov-SN for emacs-pretest-bug@gnu.org; Mon, 07 Apr 2008 12:01:55 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jitn4-0002O2-E9 for emacs-pretest-bug@gnu.org; Mon, 07 Apr 2008 12:01:50 -0400 Original-Received: from ceviche.home (vpn-132-204-232-194.acd.umontreal.ca [132.204.232.194]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id m37G1mIa017041 for ; Mon, 7 Apr 2008 12:01:49 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 3172EB46F1; Mon, 7 Apr 2008 12:01:26 -0400 (EDT) In-Reply-To: <001901c8984d$5a62fe80$0200a8c0@us.oracle.com> (Drew Adams's message of "Sun, 6 Apr 2008 18:18:56 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: -2.5 X-NAI-Spam-Rules: 1 Rules triggered BAYES_00=-2.5 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:94584 gmane.emacs.pretest.bugs:21922 Archived-At: >> I.e. evaluating the above code via M-: (or in your .emacs) should >> hopefully make display-buffer work correctly such that the trunk's >> display-buffer-other-frame works just as well as the one you've >> been using. > It does not. With Emacs 23, on MS Windows (emacs -Q): I evaluate only > the code snippet you sent. Then, C-x 5 C-o does what > switch-to-buffer-other-frame does: it selects the buffer; it doesn't > just display it. Hmm... so now we need to figure out whyh my code works differently from your. Maybe it's just a silly bug in my code, but maybe there's something deeper. > Perhaps someone else on Windows can try it also, to confirm, but > that's what I see. I believe you. >> >> The difficulty is that select-frame-set-input-focus doesn't >> >> do the right thing in my situation: it raises the current frame >> >> whereas it shouldn't be doing that. >> >> > If `select-frame-set-input-focus' doesn't work in your >> > situation, then perhaps that's the place to debug? >> >> It is documented as doing a "raise", but in the display-buffer case we >> don't want to do a raise (at least not for window managers where the >> window with focus should not need to be raised). So using >> select-frame-set-input-focus can't be right (unless we not only change >> its code but also its spec). > I see. Do you think that's a problem, in practice, for this particular > command (which several of us even advised tossing out)? I'm talking here about fixing display-buffer not just display-buffer-other-frame. > If it's important to you that the initially selected window not have its frame > raised, then perhaps another function is needed - a function like > `select-frame-set-input-focus', but which doesn't raise the frame. Or perhaps > add an optional arg to `select-frame-set-input-focus' to express that > alternative behavior. Maybe, maybe not: maybe the raise is the part that makes it work. That's what I'm trying to figure out. Stefan