From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.help Subject: Re: bind a hotkey to toggle variable Date: Tue, 14 Jul 2009 10:46:13 +0900 Organization: NEC Electronics Message-ID: References: <4314c1f70907110928j2b12bc95v51e4c785a9fee6f2@mail.gmail.com> <428DAEDA942B4A9B8ABBD00EF40F54DB@us.oracle.com> <4314c1f70907121936r6a74003aya2bb42b1bfb56d35@mail.gmail.com> <4314c1f70907122012j638e717cw984a0defd893455f@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1247539249 8423 80.91.229.12 (14 Jul 2009 02:40:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jul 2009 02:40:49 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jul 14 04:40:41 2009 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 1MQXwf-0000Ln-5E for geh-help-gnu-emacs@m.gmane.org; Tue, 14 Jul 2009 04:40:41 +0200 Original-Received: from localhost ([127.0.0.1]:50748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQXwe-0006BW-Ki for geh-help-gnu-emacs@m.gmane.org; Mon, 13 Jul 2009 22:40:40 -0400 Original-Path: news.stanford.edu!headwall.stanford.edu!newsfeed.esat.net!colt.net!feeder.news-service.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 53 Original-X-Trace: individual.net j6MwqDBDUCo6fdfHMcuMCQ4jErM4qBreMk0PaLIvwa2UZo/cpM Cancel-Lock: sha1:HtAcwWWRhTDm1AjG/je/CTt9LYk= sha1:BeGZYyOHrocTFVjMtowGAg0qPEU= System-Type: x86_64-unknown-linux-gnu Blat: Foop Original-Xref: news.stanford.edu gnu.emacs.help:170852 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:66048 Archived-At: "Drew Adams" writes: >> > Frankly, I'm always surprised that, 20-30 years after the >> > introduction of graphic displays and window managers, most >> > people still use Emacs windows, not frames, for most buffers. >> >> Doesn't seem particular surprising -- Emacs windows are generally much >> easier to manipulate and behave better than frames controlled by the >> system's window manager, especially for short-lived windows > > So out of the box, yes, you're right; vanilla Emacs doesn't provide > the same degree of user control for frames as it provides for > windows. That's part of what I meant by Emacs dev being > window-oriented. So users who want that must, on their own, provide > code and bind keys to manipulate frames easily (move/resize in various > ways, promote/demote, select, delete, whatever). Emacs simply doesn't _have_ as much control over them. There are many complicating factors that arise when using WM windows that don't when using "internal" windows (which Emacs obviously has full control over). For instance: * WM window abstractions and details can differ vastly between platforms, limiting the number of assumptions Emacs can make, and the amount of control it has over position/size/etc. Even on a _single_ platform you can never really be sure, e.g., when using different WMs in X (typical overlapping WM, vs. tiling WM, etc). * WMs typically let the user do what he wants outside of Emacs (and in the case of tiling WMs, the WM itself may make other changes), meaning that while Emacs can notice layout changes, it doesn't have much control over them. Together with overlapping windows, this means that it's hard to maintain layout constraints. * The presence of extraneous things like title bars, frames, etc, make it harder to do layout. I emphasize layout issues because that's actually one thing that makes Emacs internal windows nice -- the simpler, more controlled and dependable, tiled layout means that it's easier to automatically do something reasonable when the window configuration changes often. There have been attempts to provide an "emacsy" experience using only WM windows; Hemlock (and its predecessors), is the example that comes to come to mind (they tried very hard to make it work, e.g. "C-x 2" would shrink the current WM window, and create a new window in the space). My recollection is that while there was an initial "oh cool" factor, it always felt a bit more flaky than Emacs internal windows do. -Miles -- Alone, adj. In bad company.