RE: bind a hotkey to toggle variable

["Drew Adams" <drew.adams@oracle.com>]

> > 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 
> (and this is despite many well-known shortcomings in Emacs window 
> manipulation, e.g., those which ECB tries to hack around).

Chicken and egg. If you make the easiest way to get in and out of a car the back
window, then, sure, most users will get in and out using the back window.

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

Otherwise, with such additions, no, there is no necessary advantage, IMO. A
short-lived frame is no more difficult to use than a short-lived window (unless
your window manager is slow). On the contrary; frames can provide more
options/flexibility for UI. A window either exists or it doesn't. A window can
exist and not be displayed, but users generally do not or cannot take much
advantage of that. Frames, on the other hand, can exist or not; they can be
visible or invisible or iconified (or thumbified, with thumb-frm.el).

> If you look at many other modern apps, they do exactly the same thing,

No, please, stop with the "modern" stuff. Apps with windows inside windows have
been around since the dark ages. Some apps fit well with that approach; others
fit less well with it. That's all. It has nothing to do with "modern". We're not
selling soap here.

> though they may not use the term "window" for their internal windows
> (maybe they call them "panels" or "widgets' or whatever) and may not
> allow as much user manipulation as Emacs does.  Still, the division in
> to large relatively static system-controlled windows (emacs 
> frames) and small more dynamic app-controlled windows within them
> seems like a pretty well established practice.

Sure it is. But no more well-established than not putting everything in the same
window-mgr window.

The point is that in Emacs you can have it all, and use whatever you like most
for a particular context. Nothing prevents you from using multiple windows in a
frame, even if you have non-nil `pop-up-frames'. Nothing prevents you from using
various features together: tabs, multiple windows, multiple frames.

But the other side of the point is that most users don't - most just use the
default behavior, which privileges windows considerably. Tabs in Emacs are still
a poor cousin, and frames are not far behind that status. And that systemic
privileging of windows in Emacs has nothing to do with fit for a particular app
or being "modern".

Those arguments are beside the point, even if we were to accord them. The reason
that Emacs privileges windows is, well, simply that Emacs privileges windows.
And the reason that Emacs users privilege windows is, well, that Emacs makes
windows the easiest way to go.

And yes, it does still surprise me a bit, after all this time.

Note: Frames and tabs are things that Emacs already has - the basis is (has
been, for a long time) there for making them useful. These are not like other
things in the wide world that are still weak or nonexistent in Emacs - "modern"
rendering, graphics, widgetry, and such.

Anyway, this is not the best place for such a discussion. That's all I have to
say about it here. We can discuss it more in emacs-devel, if you like.