From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: view mode: `q' does not delete frame Date: Sat, 3 Dec 2005 07:37:31 -0800 Message-ID: References: <87ek4ugr21.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1133624380 18514 80.91.229.2 (3 Dec 2005 15:39:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Dec 2005 15:39:40 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 03 16:39:31 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EiZTR-0006Gm-6g for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2005 16:38:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EiZTT-0000NA-GX for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2005 10:38:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EiZSK-0000B4-5A for emacs-devel@gnu.org; Sat, 03 Dec 2005 10:37:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EiZSH-00009o-I4 for emacs-devel@gnu.org; Sat, 03 Dec 2005 10:37:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EiZSH-00009Y-28 for emacs-devel@gnu.org; Sat, 03 Dec 2005 10:37:41 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EiZSR-0003Xr-Dm for emacs-devel@gnu.org; Sat, 03 Dec 2005 10:37:51 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB3FrbNo006401 for ; Sat, 3 Dec 2005 09:53:37 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB3FbZc2019953 for ; Sat, 3 Dec 2005 08:37:35 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-105-46.vpn.oracle.com [141.144.105.46]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jB3FbZSw019947 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 3 Dec 2005 08:37:35 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <87ek4ugr21.fsf-monnier+emacs@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:46933 Archived-At: >> I would prefer, of course, that if pop-up-frames = non-nil, the behavior of >> view-remove-frame-by-deleting would follow automatically (by default). > Well, I'm not sure about this: is it really true that someone who > wants view-mode to create a frame for every new buffer in view mode > would like such frame to automatically go away when they quite view > mode? To "go away"? Probably. But "to delete"? No. I know Drew always wants to delete such frames because his window-manager and use pattern make it inconvenient to have too many iconified windows. OTOH with my window manager and my usage pattern, it's the reverse: deleting frames is a major pain in the rear because when they are re-created, I have to manually place them again (and set various other attributes like size, set of workspaces they should appear in, ...). So we should have a function to "make a frame go away" (probably bury-buffer or quit-window or both) and use that, and then make this function customizable so that we can decide whether to delete or to iconify. I agree with Stefan. Iconifying is terrible in Windows and frame deletion/creation is instantaneous. Other platforms can be the other way around. And users can prefer one or the other behavior. If frame invisibility were not bugged, I think that would be a good general solution (i.e. good candidate for the default value). But it is bugged. For quite a while (Emacs 19 or 20) I made frames invisible instead of iconifying or deleting them - when bugs don't raise their ugly heads, it's an elegant solution. Most of the time spent creating a frame (at least back then, on Unix) was apparently spent defining it, not displaying it, so making an invisible frame visible again was instantaneous - and it returns to the same place it last was, with the same properties (which is Stefan's main problem with frame deletion and re-creation, IIUC). If others agree with Stefan and I, the next question would be the default value for quitting. I obviously vote for frame deletion (e.g. via quit-window), and I'm sure Stefan votes for frame iconification (e.g. via bury-buffer). As long as this is an option, the default value is of course not that important. (BTW - The problem with iconification on Windows is not just the presence of numerous unneeded icons; it's the distraction of the animated iconification: the frame visibly streams to become an icon - it doesn't just disappear and an icon appear.) Thanks for looking into this. Perhaps, after the release, we can look at fixing frame invisibility, so that could be used in cases like this. (I don't know - perhaps it's already been looked at and deemed unfixable.)