From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: special buffer frames again Date: Tue, 1 May 2007 14:04:02 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1178053494 19487 80.91.229.12 (1 May 2007 21:04:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 May 2007 21:04:54 +0000 (UTC) To: Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 01 23:04:47 2007 Return-path: Envelope-to: geh-help-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 1HizWf-00045H-VQ for geh-help-gnu-emacs@m.gmane.org; Tue, 01 May 2007 23:04:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hizd0-0001Xz-BY for geh-help-gnu-emacs@m.gmane.org; Tue, 01 May 2007 17:11:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hizcn-0001Xk-VA for help-gnu-emacs@gnu.org; Tue, 01 May 2007 17:11:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hizcm-0001XY-8t for help-gnu-emacs@gnu.org; Tue, 01 May 2007 17:11:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hizcm-0001XV-3i for help-gnu-emacs@gnu.org; Tue, 01 May 2007 17:11:04 -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 1HizWQ-0006RS-Jj for help-gnu-emacs@gnu.org; Tue, 01 May 2007 17:04:30 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l41L4Qhh014802 for ; Tue, 1 May 2007 15:04:26 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l41Ial0E024174 for ; Tue, 1 May 2007 15:04:25 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-82-223.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2662119281178053447; Tue, 01 May 2007 14:04:07 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:43460 Archived-At: > Maybe a more significant difference is that my window-manager is > configured to not auto-place new windows, so whenever Emacs > creates a new frame I have to manually place it. So remembering > placement is particularly important. I see. That would make a big difference. > I have 2 separate icon-managers: one for Emacs windows, and > another for the rest. So my Emacs icon-manager acts as a > "buffer list". So I can just select the relevant buffer > with the mouse rather than use C-x b. I see. FWIW, when I do want to iconify a frame, I actually use my own thumbnail-frame pseudo-icons, instead of iconifying to the Window task bar (http://www.emacswiki.org/cgi-bin/wiki/FisheyeWithThumbs). So the behavior is similar to that of other window mgrs: icons on the desktop vs in the task bar. (But the "icons" are really frames, so I can stack them any way I want, scroll, select text, monitor process progress, and so on.) This is not very relevant here, however. > > Thought experiment: Imagine if Emacs windows were always > > iconified instead of simply disappearing when you are done > > with them - do you think many users would complain? > > I'll bet that such a feature would be removed within 48 hours. > > I'm not sure I see the relation. `pop-up-frames' = t makes Emacs use frames instead of windows, by default. If Emacs treated its windows the way it currently treats its frames (e.g. iconify when done), then I think more people would realize how poorly Emacs plays with `pop-up-frames' = t. > To me it's more like buffers: buffers can be displayed or > (not in which case they're like iconified, visible in the > buffer-list). The main annoyances with iconification are 1) distraction of seeing the frame zoom into an icon (at least on Windows), and 2) visible presence of the icons. When a buffer is no longer displayed, it is not apparent anywhere - unless you explicitly choose to show a list of buffers. If a buffer list were always visible, taking up screen real estate, and if the displayed buffers zoomed into that buffer list in an animated way whenever you undisplayed them, then, yes, your analogy would fit, and undisplay of a buffer would be as annoying as undisplay of a frame is now. But buffers and Emacs windows don't suffer from these distractions - they just disappear (Poof!). That's what should happen to most frames (including *Help* and *Completions*), when you are finished with them (even temporarily). Choosing a completion or hitting C-g or hitting q in *Help* should never iconify the frame; it should just delete it. As you mention, as long as a buffer exists, you can always redisplay it via the buffer list - there is no reason to also have every undisplayed buffer in an omnipresent icon list somewhere. > Some users are bothered by the ever growing list of buffers, Not I, in any case. But that is one reason I do iconify some frames (using thumbnails). I use a short list of iconified buffers, and, for less frequently used buffers, I explicitly call upon the long buffer list (or use completion). > but they can always use C-x k when it's a problem. And that would be felt sooner to be a problem if the buffer list were displayed continually, as are icons. > And I do the same: basically all my frames are "dedicated", > so if I do C-x k, it deletes the relevant frame. Same here. And I've tweaked basic code so that the display of "temporary" buffers also goes "Poof!" when it's done. > In any case, the main problem for me with deletion of frames is > the loss of information (mostly placement). Yeah, that sounds like a bummer. If your preference for auto-iconification is based mainly on your needing to position frames manually, would you agree that frame deletion is generally better for people who don't share that window-mgr limitation? > > FWIW, the OP specifically pointed to the annoyance of > > iconification - he was looking for a way to eliminate that. > > Maybe you have a suggestion for him, explaining how you > > avoid this annoyance - or how you avoid being annoyed by > > it ;-)? > > I don't think the problem is iconification, but it's the accumulation of > frames: so a better solution might be to reuse a special frame > dedicated to those temporary buffers. That might be worth considering, but there can often be multiple such temporary buffers at any time. I, for instance often display *Help* during minibuffer completion. In any case, I think the problem the OP mentioned was not accumulation of frames, but iconification, and the fact that the iconified frames remained iconified when he tried to access them again. *Completions* and *Help* were sitting there as icons, making it impossible to see what was in them without explicitly deiconifying them. Here is what he said: Tyler> This also affects help windows. For example, if I c-h v, then use > completions to select the variable I want to see, and then exit the > help window with q, I end up with a completions frame and a help > frame, both minimized on the toolbar. They update themselves with > subsequent calls to help or completions, but don't restore themselves > to be visible when they do so. and > the window minimizes itself, and stays minimized... > this means I can't see the window without selecting its icon... Perhaps one improvement here would be to raise frames whenever their buffers are updated. But that might not always be desirable, depending on the frame and the context. Frame deletion still gets my vote.