From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Mark T. Kennedy" Newsgroups: gmane.emacs.bugs Subject: Re: switch-to-buffer-other-frame fails to pop-up window Date: Fri, 07 Dec 2007 11:39:14 -0500 Message-ID: <47597732.6010608@diamondbackcap.com> References: 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 1197045998 2585 80.91.229.12 (7 Dec 2007 16:46:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2007 16:46:38 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 07 17:46:48 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 1J0gLZ-0002K4-QJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Dec 2007 17:46:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0gLI-0008Rz-Pj for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Dec 2007 11:46:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0gLC-0008Qa-1m for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2007 11:46:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0gLB-0008PO-1W for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2007 11:46:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0gLA-0008PE-PL for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2007 11:46:16 -0500 Original-Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound7-sin-R.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J0gL9-0002Rk-6Y for bug-gnu-emacs@gnu.org; Fri, 07 Dec 2007 11:46:16 -0500 Original-Received: from outbound7-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound7-sin-R.bigfish.com (Postfix) with ESMTP id CBCC8127DD96 for ; Fri, 7 Dec 2007 16:38:19 +0000 (UTC) Original-Received: from mail194-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound7-sin.bigfish.com (Postfix) with ESMTP id 7FAD5D4805D for ; Fri, 7 Dec 2007 16:38:19 +0000 (UTC) Original-Received: from mail194-sin (localhost.localdomain [127.0.0.1]) by mail194-sin-R.bigfish.com (Postfix) with ESMTP id 0D8C8C504EF for ; Fri, 7 Dec 2007 16:38:23 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 63.119.74.215; Service: EHS Original-Received: by mail194-sin (MessageSwitch) id 119704550244862_4524; Fri, 7 Dec 2007 16:38:22 +0000 (UCT) Original-Received: from smtp.diamondbackcap.com (unknown [63.119.74.215]) by mail194-sin.bigfish.com (Postfix) with ESMTP id 9CF44670080 for ; Fri, 7 Dec 2007 16:38:20 +0000 (UTC) Original-Received: from mail.diamondbackcap.com ([10.21.1.222]) by smtp.diamondbackcap.com with InterScan Messaging Security Suite; Fri, 07 Dec 2007 11:39:49 -0500 Original-Received: from s1.diamondbackcap.corp ([10.21.2.200]) by mail.diamondbackcap.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 11:39:38 -0500 Original-Received: from d1.diamondbackcap.corp (d1.diamondbackcap.corp [10.21.2.1])by s1.diamondbackcap.corp (8.13.6/8.13.6) with ESMTP id lB7GdXS7008116; Fri, 7 Dec 2007 11:39:34 -0500 Original-Received: from d1.diamondbackcap.corp (localhost.localdomain [127.0.0.1])by d1.diamondbackcap.corp (8.13.6/8.13.5) with ESMTP id lB7GdEcr002346; Fri, 7 Dec 2007 11:39:19 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 In-Reply-To: X-OriginalArrivalTime: 07 Dec 2007 16:39:38.0504 (UTC) FILETIME=[C21C6880:01C838EF] X-imss-version: 2.049 X-imss-result: Passed X-imss-scores: Clean:72.10217 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:17141 Archived-At: Drew Adams wrote: >> 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. > i guess it boils down to whether you see frames and windows as orthogonal or hierarchical concepts. if you see them as orthogonal, then you want "c-x 5 b" to always make sure there is a second frame. if you see them has hierarchical, then you want to see nested "green" behavior: first look for an existing second window, then for an existing second frame, and only failing both, create a new 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. > do you think it is worth while to catalog the styles of use? as a prelude to finding a way to better support them? >> 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'. > i found that when i hunted through the source. i call: (defun my-info (node) (let ((info-buffer (get-buffer "*info*"))) (if info-buffer (progn (set-buffer info-buffer) (let ((new-info-buffer (clone-buffer nil t))) (switch-to-buffer-other-frame new-info-buffer) (info node new-info-buffer))) (info node)))) from a bash shell function called "info" via emacsclient in order to get that behavior. seems to work right. >> 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*. > > right - i want a separate help buffer per frame without having to rename it by hand. i tried to do that by hooking help-mode.el's "help-buffer" function (which computes the appropriate help buffer name) but i could not get it to discover the containing frame object. by the time 'help-buffer' was called, the magic minibuffer implementation arranged for the magic minibuffer frame (not a dedicated minibuffer frame like the one you use but probably a magic one to allow sharing of the minibuffer across different real buffer frames) to be the 'selected-frame'. you can see this by doing "M-: (selected-frame)' after a fresh "emacs -Q" and then repeating after popping up a second frame. once you've popped up a second frame, '(selected-frame)' under "M-:" always returns the magic minibuffer frame (which i think is a bug). /mark This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback. Any representation to the contrary is unintentional. This communication is intended only for the person(s) to whom it is addressed. If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted. If you have received this in error, please notify the sender immediately by e-mail and delete this message. All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to a rchival and possible review by someone other than the recipient. This notice is automatically appended to each e-mail message leaving Diamondback.