Re: Infrastructural complexity.

[martin rudalics]

> I agree with Miles here: it's a non-starter.  If you want other reasons
> for it, think about the difficulties we face already with timing issues
> in requests for resizing/moving frames and/or controlling focus of newly
> created frames.  We have lots and lots of bugs there, most of which are
> a nightmare to fix because we're at the mercy of the WM.

I agree with you and Miles that WM interaction is problematic.  But if
we don't use frames then IMHO framelets, tear-off windows and multiple
tool and/or menubars are non-starters too.  And here we apparently
disagree.

>> In three steps: (1) save a frame's window configuration, (2) tear off a
>> window from that frame and re-purpose it into another frame, (3) restore
>> the window configuration saved in step (1).  Gets you two windows with
>> the same identity.  No fun here, no fun at all ...
>
> I think such window-configurations shouldn't save window identities.

`current-window-configuration' combined with `set-window-configuration'
does preserve window identities.

> Especially if one wants to be able to restore one window-configuration in
> a different frame (and/or save that config into a file).

These would have to become different functions anyway and would always
have to create a new window.

>  In other words, I think that the issue of window-identity w.r.t
> window-configurations is one where there's no way to win.  I think the
> least breakage will happen when we give up on preserving those
> identities.

We currently do not have any problems with window identities.  So why
introduce problems by trying to preserve a window's identity when
tearing it off?

martin