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: pop-up-frames inconvenience Date: Mon, 5 Jun 2006 23:53:01 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1149576906 16073 80.91.229.2 (6 Jun 2006 06:55:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 6 Jun 2006 06:55:06 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 06 08:55:03 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FnVSk-0006cq-0r for ged-emacs-devel@m.gmane.org; Tue, 06 Jun 2006 08:54:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FnVSj-000639-J9 for ged-emacs-devel@m.gmane.org; Tue, 06 Jun 2006 02:54:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FnVR9-0005bp-VJ for emacs-devel@gnu.org; Tue, 06 Jun 2006 02:53:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FnVR8-0005aw-Ie for emacs-devel@gnu.org; Tue, 06 Jun 2006 02:53:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FnVR8-0005as-Dd for emacs-devel@gnu.org; Tue, 06 Jun 2006 02:53:10 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FnVYR-0005q6-Lz for emacs-devel@gnu.org; Tue, 06 Jun 2006 03:00:43 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k566r5do006850 for ; Tue, 6 Jun 2006 00:53:05 -0600 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-105-128.vpn.oracle.com [141.144.105.128]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k566r4RQ004703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 6 Jun 2006 00:53:05 -0600 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:55744 Archived-At: > If I understand Sam's complaint, this behavior (with the > possible exception of message-send-and-exit) is not at all > new to CVS Emacs. indeed this might be wrong time (as Emacs is approaching a release) but this is definitely the right place to discuss _design_ issues related to multi-frame operations. Yes. to put it bluntly, pop-up-frames does not work as one would expect it to, requiring plenty of hacks to make, e.g., separate minibuffer frame usable. I couldn't agree more (except a standalone minibuffer presents no problem that I've seen), and I have been saying so (also bluntly) for some time. Out of the box, Emacs just does not play well with pop-up-frames=t. People either give up using that option, or they end up customizing and tweaking the hell out of Emacs to get it to behave reasonably. Most, I suspect, take the former route: they play with p-u-f=t briefly, discover that it is broken in different ways, and go back to using Emacs windows. The last thing anyone wants is fifty million forgotten frames littering the desktop, not to mention struggles with frame focus. What Emacs does with windows should be available for frames also - the same convenience and smart behavior, but adapted to a frames world. Emacs is marvelously adroit with windows, and miserably maladroit with frames. two independent paths appear to be promising: 1. make all frames that are not explicitly created by the user "dedicated" (then quit-window will delete them) 2. some buffers are not "stand-alone" but tied to the current (minibuffer) operation (e.g., *Completions*). maybe they should be prevented from creating their own frames. maybe completion should be done via a non-buffer mechanism (like baloon help?) I'm not crazy about either one, frankly. If we go after this problem, let's approach it slowly and do it right. There are no doubt lots of "solutions", as the problem itself is multiple: there are lots of tiny (and some maybe not so tiny) problems with Emacs + pop-up-frames=t. I'm skeptical of a "y'a qu'a" ("all you need to do is") solution here. I'm not sure about #1. IIUC, it means reinterpreting (or, rather, imposing a single behavioral interpretation on) what it means for a frame or window to be "dedicated". Maybe I'm misunderstanding you (& Stefan), but I think the current notion of special-display buffer is, on the contrary, open to any interpretation/behavior a user wants to give it. If #1 is about a new, separate (orthogonal) mechanism/feature, then that approach might be OK, but if it means coupling the current notion of dedicated window with p-u-f=t, then I think that's too restrictive. I use one-buffer-per-frame, but I change the buffer in the frame quite often. Just as with windows you can use C-x f (not just C-x 4f), so with frames you can reuse a frame with a different buffer. I don't want to lose that. I certainly agree that there should be a simple way (e.g. quit-window) to delete a frame (I use a kill-buffer substitute that also deletes the window/frame, in addition to quit-window). I would prefer that we try to attack the individual problems that using p-u-f=t poses in practice one by one. These might be solved individually, without necessarily requiring any new mechanism or single remedy. I've gotten by quite well with this approach so far. What I find (feel) is that not enough testing is done with p-u-f=t, so here and there Emacs code just doesn't DTRT wrt this "mode". Mr X implements a new feature, and doesn't bother to make it friendly also to p-u-f=t. That's not a big deal usually; it just needs to be corrected, over and over, here and there. My guess is that if the main Emacs developers were forced to live with p-u-f=t (only) for one week, within another two weeks all of the p-u-f=t problems would be solved. It would drive them bananas, and they would find ways to DTRT. I expect that fixing the isolated code problems so that Emacs DTRT is probably sufficient. But I really have no horse in this race - I too would just like to see the problems go away in vanilla Emacs. WRT #2 - The problem is real, but I am opposed to that particular "solution". I like one-buffer-per-frame (by default), and I like to use frames for everything (almost, by default). That can and should be made to work (for those who want it). I definitely want a separate frame for *Completions* - in particular! However, it needs to have its focus in the minibuffer. That's what I do in my code, and it works very well. As for everything involving pop-up-frames, using a pop-up frame for *Completions* also means, of course, that things like C-g (and other ways to exit the minibuffer) need to delete the *Completions* frame. Again, what we do correctly for Emacs windows, we need to also do correctly for frames. If the code were simply tested with p-u-f=t, all of the problems would be fixed (and they wouldn't have been created to begin with). That's the good news: the "problem" is more a mixed collection of oversights than a fundamental design flaw, IMO. It's not because most people don't use p-u-f=t that it shouldn't work well everywhere. It's not because the current code presents multiple difficulties for p-u-f=t that we should aim for a partial solution. Some people will want *Completions* to be a pop-up window, even if they otherwise use p-u-f=t. Others, like me, will want *Completions* to be in its own frame. It should be possible to satisfy both preferences (separately). There are other "temporary" buffers, like *Help*, that also pose this or similar questions, even when they don't share the focus problem that *Completions* has. There are different ways to use p-u-f=t, and that's what should be kept in mind if we try to make it work. Some people use a fixed set of frames of set sizes. Others, like me, let each buffer have its own frame and resize the frame automatically to fit the buffer. A fix to the p-u-f=t problems should be flexible in terms of a variety of p-u-f=t use cases. In sum, it would be great for Emacs developers to take seriously the impolite behavior of Emacs with pop-up-frames=t. I really welcome a discussion. Let's simply not jump to a single, hasty "solution" that doesn't allow flexibility for different users. Like anything else, people use p-u-f=t differently. With a little foresight and attention to the problems, there should be room for all.