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: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t Date: Thu, 18 Oct 2007 15:58:00 -0700 Message-ID: References: <4717D7B2.5030608@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1192748297 11661 80.91.229.12 (18 Oct 2007 22:58:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Oct 2007 22:58:17 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, dashteacup@insightbb.com To: "martin rudalics" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 19 00:58:16 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 1IieJk-0002T4-EJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2007 00:58:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IieJd-00057R-0J for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Oct 2007 18:58:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IieJX-00056G-Rs for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2007 18:58:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IieJV-00054n-MF for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2007 18:58:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IieJV-00054i-Iv for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2007 18:58:01 -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 1IieJS-0005yk-2X; Thu, 18 Oct 2007 18:57:58 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l9IMvrl3003643; Thu, 18 Oct 2007 16:57:53 -0600 Original-Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l9IHEcdq020619; Thu, 18 Oct 2007 16:57:51 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt350.oracle.com with ESMTP id 3304049301192748270; Thu, 18 Oct 2007 15:57:50 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4717D7B2.5030608@gmx.at> 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:16782 Archived-At: > > I have a dedicated *Help* frame. > > What is the semantics of a "dedicated frame"? I should have said "special-display". (add-to-list 'special-display-buffer-names (list "*Help*" 'my-display-*Help*-frame...)) > > Because of `pop-up-frames', `display-buffer' uses another > > frame, but I do sometimes switch to a different buffer in > > the same window. And I do sometimes split a window, so my > > frames are not always `one-window-p'. > > If you "dedicate" a frame to the Help buffer why do you want to switch > to a different buffer in that frame? Why do you want to split that > frame's window? I don't; I never said I did. I was describing my overall use, including my use of `pop-up-frames', not my use of *Help*. You expressed some assumptions about users with non-nil `pop-up-frames' and their never reusing a window and never splitting a window. I was explaining that although I have `pop-up-frames' non-nil, I still sometimes reuse or split some windows (not *Help*, but others). > > If a new window or frame was popped up to display a view-mode > > buffer, then I expect quitting to delete the window and, if > > one-window-p, delete the frame too. > > I already explained that by default Help buffers are not dedicated thus > `quit-window' won't necessarily delete the associated frame. And I explained that I don't personally need you to delete the frame - I do that myself. Deleting the window is sufficient (for *Help* or any other buffer). > If people want that we can change the behavior of view-mode > but that would affect all clients of view-mode. Alternatively > we could make help-windows dedicated (if that helps). > > Currently `view-remove-frame-by-deleting' has to be set to get the > effect you want. We could make that non-nil by default. I don't know or care what the default value is. FWIW, I have that set to `t'. > > FWIW, my own code takes care of the latter part, so it is > > enough for me if the view-mode code simply does `quit-window'. > > > > If a new window or frame was not popped up to display the > > view-mode buffer, that is, if I manually switched to it in > > an existing window, then I want quitting that buffer/mode > > to restore the previous buffer that was in that window. > > > > Summary: > > if pop-up, then quit => delete the window/frame > > if not pop-up, then quit => restore previous buffer for window > > Suppose you (1) pop up a view-mode window, (2) display a non view-mode > buffer in that window, (3) display a view-mode buffer in that window, > and (4) quit view-mode. Whatever `view-mode-exit' does now, you'll > complain. No I won't. In that case, you can show again the non-view-mode buffer that inhabited the window before the view-mode buffer that was quit. If there was a buffer in the window before the view-mode buffer is placed in it, then it's OK to show that buffer after quitting the view-mode buffer. If there was no other buffer in the window before the view-mode buffer, then there is no reason to display any buffer at all there - just delete the window. And if the view-mode buffer is `one-window-p', then delete the frame also. > >>- Exiting view-mode should ideally (1) kill a window that > >> has been popped up for view-mode purposes and (2) show > >> the earlier contents of the window when it has been > >> usurpated by view-mode. > > > > That would be good. In my case, #1 is what I expect for the > > *Help* buffer. I have no problem with #2, assuming that it > > applies to buffers that were not popped up in another window. > > I wrote "ideally" and I had your usage pattern in mind. But keep in > mind that killing a window doesn't necessarily imply killing its frame. I understand. Don't worry about the frame-killing part, at least for me. My own code does that. I personally think that the test of `one-window-p' should be sufficient for deciding whether `delete-window' should also delete the frame, but I think that some others might disagree with that. For my own needs, it is enough that Emacs delete the window - my own code will then DTRT (for me) wrt the frame. > > I haven't followed the current thread closely. If you have a > > Lisp-only patch I can try, I will do that. > > It's still the patch I sent you earlier. Then I already provided my feedback, IIRC. Thanks for working on this, BTW. I realize that it is not so easy to juggle the many possibilities, including different use patterns.