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: Fri, 19 Oct 2007 08:17:37 -0700 Message-ID: References: <47186990.3030007@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 1192807115 11537 80.91.229.12 (19 Oct 2007 15:18:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2007 15:18:35 +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 17:18:34 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 1IitcQ-000246-5b for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2007 17:18:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IitcI-0000KM-HB for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2007 11:18:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IitcB-0000Gj-Js for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2007 11:18:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IitcA-0000F0-Ni for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2007 11:18:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IitcA-0000EZ-84 for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2007 11:18:18 -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 1Iitc1-0008UJ-8C; Fri, 19 Oct 2007 11:18:11 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l9JFI4E0007602; Fri, 19 Oct 2007 09:18:04 -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 l9J6ud4c019079; Fri, 19 Oct 2007 09:18:04 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-153.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3305357821192807056; Fri, 19 Oct 2007 08:17:36 -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: <47186990.3030007@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:16787 Archived-At: > > I should have said "special-display". > > (add-to-list > > 'special-display-buffer-names > > (list "*Help*" 'my-display-*Help*-frame...)) > > I did understand you the first time. The Elisp manual tells me: > > By default, special display means to give the buffer a dedicated > frame. > > No special semantics for "quitting" or "deleting" dedicated frames are > given. There's a short remark in the Emacs manual > > "Killing the special buffer deletes its frame automatically." > > but I'm not sure whether you want to kill the Help buffer and I don't > know what to do when you manually switched to another buffer in that > frame in between. As I said, I do *not* switch to another buffer in the same window as *Help* (which is dedicated). I don't think that's even possible, but I could be mistaken. As far as I am concerned, quitting *Help* can delete the buffer or the window. Either way, my own code will then delete the frame. For me, at least, quitting *Help* should never just do nothing (which it does sometimes), and it should never iconify the frame (which it does sometimes). All that's needed for my own use case is for `q' to call `quit-window', as I've said before. I can't speak for others, who might have different needs. > >>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 you do not "reuse" Help windows I don't understand why the proposed > patch doesn't work for you. You would have to give me a recipe to > reproduce the incorrect behavior. Problems may arise if and only if a > Help window was reused to display another buffer. I don't recall how well your patch worked for me. I tried it and reported what I saw to you quite a while ago. I don't even have the patch anymore. I sent my recent message in reply to yours, which summarized the possible use cases. I mentioned that, FWIW, my own preferred *Help* behavior was not represented in your summary, and I indicated the *Help* quitting behavior that I would like to see. If your patch satisfies that, then there is no problem. If, however, the *Help* window is not deleted (`q' does nothing) or the *Help* frame is iconified, then it still does not provide the behavior I need. And so on, wrt non-dedicated buffers and what I said about them in my last mail (quoted below). > >>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). > > Your personal modifications won't be of any help to other Emacs users. > Let's make this generally usable. I proposed for vanilla Emacs that `delete-window' delete also the frame if the window is alone there (`one-window-p). I think that would be "generally usable". But some people with different use cases disagreed. I also proposed that an option be available to at least let users choose that behavior. That too was rejected. So anyone who wants the delete-sole-window-also-deletes-frame behavior will need to either use my code or roll his/her own. (FWIW, my code is here: http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs.) If you would simply delete the *Help* window upon quitting, then I would be happy wrt *Help*, and no one else would be required to share my desire for the frame also to be deleted. Again, (1) `q' = `quit-window' suffices for me, and probably for some others in your use-case list. Alternatively (for me), (2) deleting the *Help* window or (3) the *Help* buffer is sufficient. Any of those 3 approaches works for me. > > 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. > > I already explained that tracking the appearance of buffers in a window > is non-trivial and has to be done in `window-configuration-change-hook'. > So far the decision about how to quit view-mode must be established when > _entering_ view-mode. You asked me to describe the behavior I prefer, so I did. I think that what I wrote (and you just quoted) makes sense; it is reasonable behavior to expect: When you quit view-mode, if there was another non-view-mode buffer in the window prior to the viewed buffer, then return to it; otherwise, delete the window. More exactly, return to the most recent non view-mode buffer previously in the same window, if any; if none, then delete the window. I doubt that anyone wants to return to a view-mode buffer, but I might be mistaken. Even that would be OK: if there was any buffer at all in the window before the view-mode buffer, then return to it; if not, then delete the view-mode window when quitting view mode. What is definitely not useful is to put some other buffer in the window, which was never shown in that window before. When a view-mode window pops up (new frame), quitting the mode should not stick some unrelated buffer in that window. In this use case, think of a window such as *Help* as a (non-modal) dialog box. When you quit that dialog box, you don't want its window to remain, filled with some extraneous buffer that you happened to access half an hour ago or 3 days ago. That just doesn't make sense. Anyway, those are the behaviors I see as reasonable and unreasonable. I cannot speak to the difficulty of implementation. I can say, however, that Emacs 20 has no such problems. I'm no expert on this, but my impression is that the view-mode code (or perhaps it is the help-mode code) is trying to be too smart these days, and it fails to be smart enough. It was better, IMO, when it was simple, reliable, and stupid. Users then knew what to expect; the behavior was predictable and reasonable. Emacs 22.1 sometimes does nothing for `q' in *Help*, sometimes deletes the window, and sometimes iconifies the frame - there is a UI problem. (I'm not speaking about your patch; I'm speaking about Emacs 22.1.) > > And if the view-mode buffer is `one-window-p', then delete the frame > > also. > > If people agree that typing `q' should be allowed to unequivocally > delete a frame. Again, if people don't agree about deleting the frame (and I'm sure that some do not agree), there is still no problem. Those who want that behavior can use my code or roll their own. It would be preferable, however, that they have the possibility of choosing that behavior within vanilla Emacs (e.g. via an option). I admit that I don't fathom the view-mode and help-mode code. I can only speak as a user here. Maybe help mode should not use view mode, but should deal with quitting itself; I don't know. I do know that things are not quite right yet (in Emacs 22.1). Again, I sincerely thank you for trying to make sense of this and improve the code. I know it's not easy to satisfy everyone. I hope it's clear at least, what I would like to see, if possible.