all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Miles Bader <miles@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: bind a hotkey to toggle variable
Date: Tue, 14 Jul 2009 10:46:13 +0900	[thread overview]
Message-ID: <buo3a90nije.fsf@dhlpc061.dev.necel.com> (raw)
In-Reply-To: mailman.2432.1247497373.2239.help-gnu-emacs@gnu.org

"Drew Adams" <drew.adams@oracle.com> 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.


      parent reply	other threads:[~2009-07-14  1:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-11 16:28 bind a hotkey to toggle variable tiefeng wu
2009-07-12 18:27 ` Drew Adams
     [not found]   ` <4314c1f70907121936r6a74003aya2bb42b1bfb56d35@mail.gmail.com>
2009-07-13  3:12     ` tiefeng wu
2009-07-13  6:50       ` Drew Adams
2009-07-13  8:24         ` Peter Dyballa
2009-07-13  8:47           ` Drew Adams
2009-07-13  9:15             ` Peter Dyballa
2009-07-13 15:02               ` Drew Adams
2009-07-13  9:10         ` tiefeng wu
     [not found]       ` <mailman.2406.1247467827.2239.help-gnu-emacs@gnu.org>
2009-07-13 10:10         ` Miles Bader
2009-07-13 11:06           ` Peter Dyballa
2009-07-13 15:02           ` Drew Adams
     [not found]           ` <mailman.2432.1247497373.2239.help-gnu-emacs@gnu.org>
2009-07-14  1:46             ` Miles Bader [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=buo3a90nije.fsf@dhlpc061.dev.necel.com \
    --to=miles@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.