Re: Infrastructural complexity.

[Miles Bader]

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

Why do you keep talking about "tear-off windows"?  They aren't the focus
of this discussion.

As I said in my previous message:  [[I don't know if "tear off" windows
are a goal or not, 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."']]

In other words, they are (1) not a required feature, and (2) represent
and explicit user _escape_ from the automatic layout.  The focus of this
discussion -- AFAICT -- is the automatic layout _not_ the
optional-and-fringe-feature of tear-off-windows.  While tear-off windows
may be an interesting feature, and kinda cool, they are not a
particularly important feature, and are _not_ the point of the current
conversation.  It'd be fine if whatever solution is decided completely
lacks that feature.

>> 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?

[completely OT at this point, but: to place windows.  By default, most
tiling WMs, do so automatically, unless the user or the app takes the
trouble to setup some (non-default and WM-specific) mechanism to do so.]

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

I dunno; I haven't looked at the implementation details.  It doesn't
sound particularly hard to me, offhand, to have the Emacs code move an
internal Emacs window structure to another parent frame (preserving any
pointers/whatever, but changing the frame pointer etc) in this case, but
I'll have to demur from arguing about it, since I don't have any
detailed basis on which do so.

Since tear-off windows are not very important though, it doesn't really
matter.  An implementation which creates a new Emacs window inside a new
frame seems acceptable to me as well.  Or simply not having tear-off
windows.

-Miles

-- 
Learning, n. The kind of ignorance distinguishing the studious.