Re: Infrastructural complexity.

[martin rudalics]

> AFAIK, the problem people are trying to solve right now is a way of
> increasing the power of emacs _automatic_ control over window layout --
> burdening the user with the placement and moving of these sub-windows is
> exactly what we _don't_ want to do.

In my book tearing off a window does not count as automatic control.

> They certainly don't do it well, not if you want application-specific
> inter-relationships between a set of different windows (which is exactly
> what we want).

What's the purpose of tiling window managers when you can't tell them
_where_ to put your windows?

> I don't know if "tear off" windows are a goal or not,

Certainly not my goal.  This subthread was my reaction to proposals like
providing tear-off windows, toolbars and menubars for the objects we
want to handle.  I argued it can be done easily but only at the cost of
conceptually replacing windows by frames.

> but tearing off a
> emacs sub-window is an explicit user action saying "ok, I as user am now
> assuming control over this sub-window."  So _moving_ a torn-off emacs
> internal window into its own separate frame would actually be the most
> natural thing to do.

Tearing off a window and putting it into a separate frame is no synonym
for "moving" that window into a separate frame.  You have to make a new
window and you break all overlays with a 'window property in the old
window's buffer and all references to that window stored in running
applications (although for the user the new window appears the same as
before).  So if you consider tearing off windows "a natural thing to do"
you only raise false hopes.

martin