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: Usage examples of dedicated windows and popup frames? Date: Fri, 8 Jul 2011 09:11:50 -0700 Message-ID: <9625F1599164451FAD53BCA4328DABFA@us.oracle.com> References: <871uy0n9ch.fsf@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1310141821 27307 80.91.229.12 (8 Jul 2011 16:17:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Jul 2011 16:17:01 +0000 (UTC) To: "'Tassilo Horn'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 08 18:16:57 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QfDjc-0004ZG-5p for ged-emacs-devel@m.gmane.org; Fri, 08 Jul 2011 18:16:56 +0200 Original-Received: from localhost ([::1]:60439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfDja-0006rP-O4 for ged-emacs-devel@m.gmane.org; Fri, 08 Jul 2011 12:16:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfDeu-0005ZB-1U for emacs-devel@gnu.org; Fri, 08 Jul 2011 12:12:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QfDer-0004DY-NS for emacs-devel@gnu.org; Fri, 08 Jul 2011 12:12:03 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:63389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfDer-0004DM-96 for emacs-devel@gnu.org; Fri, 08 Jul 2011 12:12:01 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p68GBwYZ029971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2011 16:11:59 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p68GBvVG026057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jul 2011 16:11:57 GMT Original-Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p68GBqbQ030741; Fri, 8 Jul 2011 11:11:52 -0500 Original-Received: from dradamslap1 (/10.159.32.31) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Jul 2011 09:11:51 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <871uy0n9ch.fsf@member.fsf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Thread-Index: Acw9fDdO1B6/uf1uQOChshlBM/++igAAGlGg X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E172C50.0050:SCFMA922111,ss=1,re=-4.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141803 Archived-At: > Since lately I've read of many people on this list that they are using > dedicated windows, dedicated minibuffer frames, and popup frames... > [I would like some] help finding some appealing overall configuration > that just works for me. I'm happy to see interest in using frames more with Emacs! The more people try, the more they will encounter a few things, as you did, that don't quite work right. Bringing attention to such problems is a good thing. IMO, it's been too bad that Emacs Dev has long more or less neglected the non-nil `pop-up-frames' case. I'm not faulting anyone - that's probably to be expected, since most people use nil `pop-up-frames'. But it's a chicken-and-egg thing too: People who do try non-nil `pop-up-frames' generally give up, precisely because of the problems they encounter and the lack of obvious ways to work around them. Problems such as those you ran into. And Emacs Dev is also consequently at a disadvantage when someone who does use `pop-up-frames' reports a frames-related bug. Because I have workaround code to deal with such problems, when I report a bug involving some frame behavior I need to provide also my setup code (or a pared down version of it) to help developers reproduce the bug. This can mean a lot of extra work for both me and the developer investigating (e.g. Martin). > And basically it's not that bad. Good to hear. Out of the box, I think it's mostly there. But there are definitely a few wrinkles to be ironed out. > But after using it for an hour, I have more than 10 open emacs > frames now. Most of them were opened for showing completion > possibilities, but after I've finished completion they became > useless. It would be great if those would be > closed automagically... I use several frames at once, and that's not a problem in general for the frames I want to continue working with. I can easily work with a bunch of them at once. (Thumbifying is handy for this: http://www.emacswiki.org/emacs/FisheyeWithThumbs.) But what _is_ a problem are frames that get popped up for temporary purposes and then remain - as you mentioned wrt *Completions*. This is actually not that common aside from *Completions*, but it does happen occasionally. It would be great for Emacs to have a good, general solution. In my own use, I: 1. Use a dedicated frame for *Completions*. 2. Use a standalone minibuffer frame. 3. Redirect the *Completions* frame's keyboard input (focus) to the minibuffer frame. 4. Automatically delete the *Completions* frame when completion is finished. (The first three are provided by `oneonone.el', the last by Icicles.) I'm not suggesting that this should be the way to go for a general Emacs solution (dunno). I'm just mentioning that it is what I do - just one data point to consider. I've made it available and mentioned it to Emacs Dev for many years now. I've used it everyday in Emacs versions from 20 through 24, and it works for me. I think that Stefan also uses a standalone minibuffer frame and non-nil `pop-up-frames'. But I think he uses (weakly) dedicated windows pretty much everywhere. I generally use normal (not dedicated) windows. I use (fully) dedicated windows only for buffers with names `*...*'. Stefan presumably never changes the buffer shown in a given window; I do (e.g. `C-x f', `C-x C-v') - in normal windows. It would be interesting to see Stefan's solution to the problems/annoyances, i.e., to see his personal setup. But AFAIK he has never exposed his setup, let alone proposed its frame-oriented solutions for Emacs. Like you, Tassilo, I would like to see a workable-out-of-the-box solution for non-nil `pop-up-frames' (or whatever the Emacs 24 equivalent will finally turn out to be) - that is, for letting users use frames in a general way. I have my own solution, but I'm also interested in Emacs providing something out of the box. I've solved the *Completions* problem for myself, by following the logic of completion and getting rid of the *Completions* frame when it is no longer needed. Completion is in effect a dialog, and when that dialog is finished there is no longer any reason to show *Completions*. But now and again (rarely) I run into a similar problem wrt other "temporary" pop-up frames such as the list of flagged or marked files for Dired operations. I make `*...*' buffers be "special-display", so they get their own dedicated windows/frames, and their frames hang around after the "temporary" dialog is finished (e.g. the Dired operation). To me this is a (minor) hassle. Emacs should IMHO treat such a dialog as what it really is: a (non-modal) user _dialog_. Displaying a list of files and asking if you really want to delete them is fine, but that files display should then disappear (duh) after you've answered the question, regardless of whether it is in a separate frame, dedicated window, etc. Emacs Dev handles the pop-up window case OK here, but not the pop-up frame case - see, e.g., bug #7533. To me, this kind of thing should be a no-brainer (in terms of need to fix, not necessarily in terms of ease of implementation), but the "second-class citizenship" of frames in Emacs effectively relegates it to the dust bin. ;-) If more people become interested in making frames work then it's likely there will be more attention to fixing such problems. > Long story short: it would be nice if some people with non-standard > window/frame settings could share and briefly explain their > configuration. I'm very interested. Me too. The more the merrier. I'm very glad to see people take interest in the problem. No doubt this is due partly to Martin's recent changes to the display-buffer code. And no doubt those changes will affect how such problems should be handled going forward. No doubt I will need to update my own way of dealing with these problems, since `pop-up-frames' is being deprecated. If you are interested in my settings, which still work with Emacs 24 but which also still use `pop-up-frames' so far, you can see a description (and code) here: http://www.emacswiki.org/emacs/OneOnOneEmacs Add to that Icicles's auto-deletion of the *Completions* frame. At various points in the completion code I call a function that removes the *Completions* window. And in the case where that window is in its own dedicated frame, it deletes the frame (it's actually a bit more complicated, but that's the idea). That's about it. > And maybe it's a good idea to ship emacs with some predefined setups > users can easily try out and then extend to find one that suits them > best, for example, the current default window oriented configuration, a > more frame oriented configuration, and a frame oriented configuration > with a dedicated minibuffer frame, too. 1+ !