From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: RE: display-buffer-other-frame - useful? doc string? Date: Sun, 6 Apr 2008 18:18:56 -0700 Message-ID: <001901c8984d$5a62fe80$0200a8c0@us.oracle.com> References: <002401c8820f$7d6042c0$0600a8c0@us.oracle.com><000001c8977b$146abc10$0200a8c0@us.oracle.com><000001c897bb$26e5ebe0$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1207531166 18228 80.91.229.12 (7 Apr 2008 01:19:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Apr 2008 01:19:26 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 07 03:19:57 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 1Jig1c-0000Yk-U6 for ged-emacs-devel@m.gmane.org; Mon, 07 Apr 2008 03:19:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jig0z-0007Dy-KO for ged-emacs-devel@m.gmane.org; Sun, 06 Apr 2008 21:19:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jig0u-0007As-Ad for emacs-devel@gnu.org; Sun, 06 Apr 2008 21:19:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jig0t-00078v-3b for emacs-devel@gnu.org; Sun, 06 Apr 2008 21:19:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jig0s-00078i-Jo for emacs-devel@gnu.org; Sun, 06 Apr 2008 21:19:10 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jig0s-0001pB-DA for emacs-devel@gnu.org; Sun, 06 Apr 2008 21:19:10 -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 1Jig0s-00017A-6f for emacs-pretest-bug@gnu.org; Sun, 06 Apr 2008 21:19:10 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Jig0o-0001oh-KC for emacs-pretest-bug@gnu.org; Sun, 06 Apr 2008 21:19:09 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jig0o-0001mt-4R for emacs-pretest-bug@gnu.org; Sun, 06 Apr 2008 21:19:06 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m371Ivi6005341; Sun, 6 Apr 2008 19:18:57 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m3708Axm017552; Sun, 6 Apr 2008 19:18:57 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3640234361207531128; Sun, 06 Apr 2008 18:18:48 -0700 Original-Received: from dradamslap1 (/141.144.64.84) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 06 Apr 2008 18:18:48 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AciYSZpeGVzOvX6jQBScCNM7II7EkwAAUm/A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:94541 gmane.emacs.pretest.bugs:21916 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. Perhaps someone else on Windows can try it also, to confirm, but that's what I see. > >> 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)? It would make a difference only when the window selected before the command was not in the front frame, and only for a window mgt policy that gives a frame focus without raising it. I'd say that the command as I implemented it (or equivalent behavior with a different implementation) is better than nothing (and much better than what exists today). If you improve the command to not also raise the selected frame, so much the better. If not, no big deal - just clarify the behavior in the doc string wrt raising the frame. I don't think it's a big deal. 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. In any case, the current behavior is inappropriate.