Re: Infrastructural complexity.

[Miles Bader]

martin rudalics <address@hidden> writes:
>> Why do you keep talking about "tear-off windows"?  They aren't the focus
>> of this discussion.
>
> This subthread was triggered by the framelet proposal which introduced
> tear-off windows together with separate tool/menu/tabbars.

Nonetheless, that was a minor and optional detail, not the focus of the thread.

> The idea or introducing such features was the premise for my initial
> posting which you tend to ignore all the time.  I said that if we want
> these sort of things then we should use frames instead of windows.  I
> never proposed to use frames unconditionally (which would be
> ridiculous BTW since I already spent quite some time modifying the
> window code).

It might indeed make implementing tear-off windows -- a minor feature --
easier, at the expensive of making the _normal_ case -- automatic layout
-- much more difficult.  Not a good tradeoff, I'd wager.

> But I have to consider the possibility that users regard issues like
> tear-off windows and separate tool/menu/tabbars important enough so I
> have to make sure which way to go.

I suppose you can consider the possibility that easy tear-off windows are
more important than automatic window layout, but it seems remote to me.

> But precisely that is the problem: If a user is allowed to escape the
> automatic layout (any maybe return to it at some later moment) we have
> to handle that.  It's already hard enough to handle the case where a
> user invokes `display-buffer' within the automatic layout in order to
> show a help or info window and later quit that window.  IIRC ECB saves
> the current window layout for that purpose leaving a one window frame,
> splits that window, makes one window the help/info window and fills the
> other window with the saved layout.  Now how to you suppose us to handle
> the case where we have to fill the space left by a torn-off window and
> reintegrate that window in the automatic layout?

I have not thought deeply about how to implement tear-off windows.

However, it doesn't matter w/r/t the issue of whether we use WM windows
or "internal" windows for the windows in question:  the actual automatic
_layout_ is equally hard or easy regardless -- the additional
difficulties of using WM windows come from the fact that it's much more
difficult for Emacs to control them (because it must go through, and
account for the vagaries of, the WM).

> to state that IMHO implementing window groups means to make considerably
> more changes to the C code than implementing framelets.

>> 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.
>
> Emacs has overlays which can have a window property which can have the
> display engine handle the overlay differently when the property matches
> the window the overlay is displayed on.  When you tear off a window the
> identity of that window changes and you have to check all overlays in
> all buffers whether any window property should get updated accordingly.

Well, obviously that difficulty only applies if we can't move the window
object ("re-purpose it") into another frame.  If we _can_, well then the
window object stays the same, so no (or at least fewer) problems.

If there's a reason we _can't_ re-purpose the window object into a
another frame, then the issues you raise may apply.  However, I do not
know if this is actually important or not -- in many cases, it's
perfectly valid to say "user code has to be prepared to deal with this."

-Miles

-- 
Non-combatant, n. A dead Quaker.