Re: Infrastructural complexity.

[martin rudalics <rudalics@gmx.at>]

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

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.

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

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?

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

Yes, and I conjectured that setting up such a mechanism is quite as
complicated as setting up an mechanism for automatic layout of windows
within an Emacs frame.  And I did this in a reply to Tom's earlier
statement, namely

 > One large difference, though, is that framelets really require
 > more changes to the C code of Emacs while window groups can
 > get away with little or 0 changes to the C code.  From some of the
 > conversation, I suspect that this is one of the big reasons that
 > there is support for window groups.

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

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

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.

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

... or separate tool/menu/tabbars (unless the latter show up in the
header lines).

martin