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: Neat features in Eclipse editor Date: Sun, 23 Mar 2008 12:49:20 -0700 Message-ID: <002001c88d1e$fce68440$0600a8c0@us.oracle.com> References: <873aqia0eh.fsf@stupidchicken.com> <873aqiw4xm.fsf@jurta.org> <47E636CB.1050607@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1206301798 23982 80.91.229.12 (23 Mar 2008 19:49:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Mar 2008 19:49:58 +0000 (UTC) To: "'John S. Yates, Jr.'" , "'emacs-devel'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 23 20:50:27 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JdWD1-0007aS-RM for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 20:50:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdWCQ-0003DN-Tb for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2008 15:49:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JdWCN-0003DH-SN for emacs-devel@gnu.org; Sun, 23 Mar 2008 15:49:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JdWCK-0003Ct-Ev for emacs-devel@gnu.org; Sun, 23 Mar 2008 15:49:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdWCK-0003Cq-7s for emacs-devel@gnu.org; Sun, 23 Mar 2008 15:49:40 -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 1JdWCJ-0004fg-PW for emacs-devel@gnu.org; Sun, 23 Mar 2008 15:49:40 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m2NJnaCZ001651; Sun, 23 Mar 2008 13:49:37 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m2NFt9Qe022005; Sun, 23 Mar 2008 13:49:36 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3622764691206301746; Sun, 23 Mar 2008 12:49:06 -0700 Original-Received: from dradamslap1 (/141.144.88.193) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 Mar 2008 12:49:05 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AciNFZE0Dd83Zi2USqG/GQqcHwraqgAAl7Uw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:93261 Archived-At: > Drew's OneOnOne efforts have pushed in the direction of > moving away from a collection of emacs managed windows > within a single frame. But IIUC the model he is pursuing > tends towards a bunch of overlapping (cascaded?) > shrunk-to-fit frames. Nonetheless, Drew has identified > a number of ways in which emacs remains seriously biased > toward reusing a small number of windows within a > single frame. Thanks for the plug, John. ;-) http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs To be clear, my own preference is for buffers to be displayed in their own frame, _by default_. "By default" means that (1) I still switch buffers in a frame (windows are not all dedicated, as in Stefan's case, IIUC) and (2) I split windows sometimes. IOW, nothing in my approach prevents you from using different buffers in the same frame, and nothing prevents you from having multiple windows in a frame. It's just that, by default, when a buffer is displayed, it gets its own window-manager (wm) window. In the parlance of the sites you cited, this apparently means that I use "floating", as opposed to tiled, wm windows. As those sites recognize, floating wm windows give users and applications the greatest liberty in frame sizing and positioning. Each of the sites you cited apparently supports not only tiled wm windows but floating windows, and two of the sites (which are apparently related) even use floating wm windows by default for some kinds of wm windows ("popup" windows). This indicates that while some people like tiling for some wm windows in some contexts, tiling is apparently not appropriate for all contexts. That's my view too: (1) multiple Emacs windows within a frame are of course tiled, and (2) I provide code for tiling frames across or down your screen (yes, that is not as general as the tiling referred to above). I use frame tiling, for instance, for ediff. My only point wrt Emacs development is that Emacs is biased toward displaying buffers in windows but not in their own frame. This bias manifests itself in temporary buffer displays such as *Help* and *Completions* and in other ways. The single, crude control knob that users have for changing this behavior is option `pop-up-frames'. But simply setting that to non-nil will not give a workable one-buffer-per-frame Emacs. In fact, it will bring you a host of secondary problems - vanilla Emacs just doesn't play very well with non-nil `pop-up-frames'. Some of the problems have to do with frame focus, but not all. Assumptions about UI interactions that are inappropriate for use with one-buffer-per-frame seem to be hard-coded. Hence battles over disposing of unneeded buffers and windows (buffer burying vs killing, view-mode quitting, etc.). It is also true that if you adopt an approach of using wm windows for buffers, then to some extent Emacs loses control and you have to deal with the particular wm you have. Some focus problems are in this category. Anyway, I've been using Emacs this way since the days of Epoch, which also introduced me to a standalone minibuffer frame. I haven't looked back since. I don't recall having had any of the frame-related problems I see in GNU Emacs when I used Epoch - it just worked. But that was a long time ago, and I might simply have forgotten the problems. Also, I was on Unix, not Windows, back then - perhaps that made a difference too. In any case, as they say, "Finie, la Belle Epoque!"