help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bind a hotkey to toggle variable


From: Miles Bader
Subject: Re: bind a hotkey to toggle variable
Date: Tue, 14 Jul 2009 10:46:13 +0900

"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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]