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 11:38:29 -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 1178044806 1990 80.91.229.12 (1 May 2007 18:40:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 May 2007 18:40:06 +0000 (UTC) To: Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 01 20:40:03 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 1HixGc-0005Di-KV for geh-help-gnu-emacs@m.gmane.org; Tue, 01 May 2007 20:40:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HixMw-00051c-Ds for geh-help-gnu-emacs@m.gmane.org; Tue, 01 May 2007 14:46:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HixMh-00051X-IU for help-gnu-emacs@gnu.org; Tue, 01 May 2007 14:46:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HixMf-00051H-3W for help-gnu-emacs@gnu.org; Tue, 01 May 2007 14:46:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HixMf-00051E-0O for help-gnu-emacs@gnu.org; Tue, 01 May 2007 14:46:17 -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 1HixGK-0004YS-9Y for help-gnu-emacs@gnu.org; Tue, 01 May 2007 14:39:44 -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 l41IdeMc006272 for ; Tue, 1 May 2007 12:39:40 -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 l41Fc5WC001458 for ; Tue, 1 May 2007 12:39:39 -0600 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-82-223.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2660294001178044713; Tue, 01 May 2007 11:38:33 -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:43444 Archived-At: > > I hate to say it, but this is a general problem with Emacs, > > IMO. Emacs is not very frames friendly, especially when it > > comes to displaying buffers that it traditionally thinks of > > as "temporary". My impression is that those who design and > > test Emacs generally do not test much using > > `pop-up-frames' = t (separate frames), and they tend to use > > functions such as `bury-buffer' to end use of a temporary > > window. The result, when you use frames, is iconification > > of frames and other uglinesses, when all you > > want is for the frame to be deleted. > > Come on, Drew, you *do* know better. At least one of the core > maintainers (i.e. yours truly) uses such a one-frame-per-buffer > setup, so there is some testing going on. And I'm thankful for that, Stefan. I still have the impression that Emacs designers and testers "*generally* do not test *much* using `pop-up-frames' = t." Emacs is generally unfriendly to `pop-up-frames' = t, IMO. If the Emacs maintainers forced themselves to use it for a week, I'll bet that a few changes (fixes) would be made ;-). I've reported bugs that were obviously the result of not testing with `t', but more needs to be done than fix the occasional oversight, IMO. I don't say that `pop-up-frames' = t should be the default value or that everyone should adopt it. I do think that testing does not reflect this use case anywhere near as much as the nil case. That it is tested a little less is OK, because most users use nil (although perhaps that is also a result, not only a cause - many people just use default values, and some who try `t' might give up because of annoyance). But there are some basic problems that are not well addressed, I think, because maintainers don't try enough stuff using `t'. > And more to the point, he specifically wants frames to be > iconified rather than deleted, Yes, I'm aware that one Emacs developer does have that preference ;-). As you and I have discussed, this can also depend on the window manager. In Windows, for instance, animated iconification can be distracting, and it stacks stuff in the task bar (even if grouped in one Emacs icon, on XP). I never understood your preference, but I respect it. I'd like to stand over your shoulder for an hour, to see how you use Emacs. I find it hard to imagine that automatic iconification of frames that are no longer in use would not be annoying, but I'm open to learning ;-). 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. > so this issue of deletion/iconification is 100% orthogonal. I don't see how that follows, but have that your way. 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 ;-)? > But yes, most other users of Emacs use few frames. > And I tend to believe that they're more efficient for it, > because unless you use a window-manager that can be controlled > efficiently from the keyboard (which basically implies a tiled > window-manager), managing frames is inefficient. Well, I won't get into a discussion now about keyboard vs mouse or use of different window managers. I do accept that keyboard use is often more efficient than mouse use, although direct access by a pointing device is much faster for some manipulations. (Mouse haters: Please don't bother to flame.) I don't know why keyboard control of frames would require a tiled window mgr - IOW, I don't understand you, here. One can control frames quite well from the keyboard. I use the keyboard to move, resize, raise, lower, delete, focus, and iconify frames - I rarely use the mouse to manipulate frames. (I don't maximize/restore frames from the keyboard, however.) Can you elaborate about what you meant? > Me? I don't even know how to touch type, so efficiency is clearly not > a concern ;-) I do touch-type, but I don't claim that that makes me particularly efficient, with or without frames. I've known more than a few programmers who use only one or two fingers and still type faster than I. Yes, I too would point out that efficiency is not the only criterion. Personally, I would prefer frames to Emacs windows for most things even if I found that using them was less efficient. People use Emacs differently, and they have different preferences. My point is that much of Emacs is not designed/implemented so that it plays well with `pop-up-frames' = t.