From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: RE: switch-to-buffer-other-frame fails to pop-up window Date: Thu, 6 Dec 2007 14:06:38 -0800 Message-ID: References: <47585776.6030604@diamondbackcap.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1196978837 31491 80.91.229.12 (6 Dec 2007 22:07:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2007 22:07:17 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: "Mark T. Kennedy" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 06 23:07:25 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J0OsG-0004M5-8q for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 23:07:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0Orz-00004w-FN for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Dec 2007 17:06:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0Orm-0008RJ-FQ for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 17:06:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0Orl-0008Qv-Ju for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 17:06:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0Orl-0008Qs-GU for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 17:06:45 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J0Orl-0008Ez-3X for bug-gnu-emacs@gnu.org; Thu, 06 Dec 2007 17:06:45 -0500 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lB6M6bvR011457; Thu, 6 Dec 2007 16:06:38 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lB6LBjlA019920; Thu, 6 Dec 2007 15:06:37 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt351.oracle.com with ESMTP id 3412165081196978786; Thu, 06 Dec 2007 14:06:26 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <47585776.6030604@diamondbackcap.com> Importance: Normal 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-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:17134 Archived-At: > interesting that you've weighed in. i read a lot of your code > while converting my .emacs from v21 to v22. you've certainly > confronted the buffer/window/frame style question in depth. > and i'm happily using many of your libraries. Not everyone agrees with my conclusions or preferences in this regard, of course. But I'm glad you find some of the code useful. > i'm not saying that use case isn't valid. i'm saying there is a clash > between the word "other" in "switch-to-buffer-other-frame" and that use > case. there is no "other" frame in the example martin gave and the use > case you prefer. and i'm supporting my case by drawing an analogy to > the behavior of "c-x 4 b" where two windows are *always* involved. I understood. Yes, C-x 5 b behaves like C-x 4 b when the buffer is displayed in a single, split frame. C-x 5 b does not create a new frame in that case, so, yes, its meaning of "other frame" is not exactly analogous to C-x 4 b's notion of "other window". > you better than anyone should have a feel for the right thing to do. > from what i can tell from a pass through the emacsWiki, you're the > buffer/window/frame usage style guru. No, not at all. Perhaps, however, I complain more than some about Emacs's treatment of frames vs windows. There are others who also typically use frames instead of windows but do so in a different way than I. And they don't necessarily use non-nil `pop-up-frames'. Stefan Monnier is one who uses frames a bit differently - I think he more or less makes each window dedicated (automatically). Some people always use a separate frame for each buffer, not just the first time a buffer is displayed (as I do). That is, they never reuse a frame for a different buffer or split its window to show more than one buffer. Some people who prefer frames don't use a standalone minibuffer (I do). Some people (including me) want deletion of a buffer or window in a one-window frame to also delete the frame. Some prefer the frame to be iconified. Others prefer that a different buffer fill the frame. There are thus different use cases and preferences. It's unfortunate that Emacs doesn't, in general, play too well with frames, but that's the way it is, so far. I think we'll eventually get it to satisfy everyone out of the box (modulo Customize), but it might take some time. Martin R. has been trying to fix some of the problems with quitting View mode and Help mode, for instance. Some of the code is complex, and it's not always obvious how to satisfy everyone. > i tend to keep one file (buffer) per frame. i like to have help & > grep & apropos and similar things pop up and down within the frame > from which they were invoked. but i like "info" and "*Messages*" > to be in separate, dedicated frames. You might want to handle those preference differences using special-display for some buffers. I do something similar for *Completions* and *Help* (in library oneonone.el). > i also find it convenient to have more than one top-level "info" frame. I just clone the current Info buffer whenever I want another copy of Info: `M-x clone-buffer'. > what got me started down this entire path was an attempt at providing > per-frame help buffers. i was annoyed when an existing help window > in frame X changed to the help response i generated when i invoked help > in frame Y. i tried to take over 'help-buffer' from help-mode.el in order > to hide a per-frame help buffer name in a frame property. but i > found that '(selected-frame)' returned the minibuffer frame when > 'help-buffer' was invoked rather than the frame from which > "help" was invoked (i sent in a separate > bug report for that but haven't heard anything about it yet). You don't want *Help* in its own frame; you want it to always open in the current frame. Is that right? That's what happens by default, if `pop-up-frames' is nil, no? emacs -Q C-x d ~ C-x 5 2 C-x b *scratch* C-h f forward-char ; opens *Help* in the same frame as *scratch* click mouse-1 on the frame with Dired, to select it C-h f backward-char ; opens *Help* in the same frame as ~ (Dired) I see *Help* in each frame. Of course, it has the same content (description of backward-char), since it's the same buffer. It sounds like maybe that's what you are annoyed by: that the buffer is the same in the different help windows. To get around that, I think you will need to do a little juggling - perhaps rename *Help* temporarily at one point or the other (automatically or manually). There is no built-in notion of per-frame help buffers. IIUC, this is not really a problem about frames or windows: your request seems to involve having multiple help buffers, not a single *Help*.