Re: Infrastructural complexity.

[martin rudalics <rudalics@gmx.at>]

 > I've been told two contradictory things.
 >
 > First I was told that `window-list' would,
 > by default, return only a list of windows within
 > one group.

When and where did I say that?

 > Then, just now, you've told me that
 > `window-list' will return all the windows in a
 > frame by default, regardless of their group.

`window-list' returns all _life_ windows on the selected (or specified)
frame and will continue to do so.  If someone wants to give additional
semantics to the FRAME argument we can do that but I see no great use to
it.

 > If `window-list' returns (by default) only
 > windows within one group (or only windows not
 > in any group) then it can return a list of windows
 > that don't add up to a rectangle.

If you read my proposal you would know that window groups always form
rectangles.  So even if `window-list' returned only windows within a
specific group these would add up to a rectangle.

 > If `window-list' returns all windows, regardless
 > of group, then sure - they add up to a rectangle -
 > but there are other problems.  For example, C-x o
 > will not DTRT.

`other-window' doesn't use `window-list'.  IF ECB is active
`other-window' will probably drop any window returned by `next-window'
if that window is not part of the current group.  But I never looked at
the implementation of `other-window' in ECB.

 > If no window groups are created there is no
 > problem, that's true.  If window groups are
 > created, then existing code is impacted by,
 > for example, the way that `window-list' has
 > no good answer to give.

No.  Window groups per se don't change the behavior of existing code.
ECB would do that.

 > Consider an ECB configuation like:
 > _______
 > | | e |
 > |_|___|
 > |_____|
 >
 > where "e" is the edit area.  Killing that
 > window stretches the control panel on the
 > left to fill the entire frame.  Ick.

Maybe, I don't know.  It might also kill the control panel or the entire
frame.

 > More useful is to say that you can't kill
 > all the edit area windows.  If you try to
 > kill the last edit area window, the error
 > is "can't delete sole remaining ordinary
 > window".   If you regard the edit area and
 > the control panels as separate frames (that
 > share a window system window) then this
 > restriction about deleting the last edit area
 > window falls out automatically.

Window groups don't know anything about edit areas.  We could specify
such semantics in window parameters, maybe.

 > I don't see how the ability to kill the frame
 > fixes the breakage to C-x 0

The semantics of what a window should display are not part of the window
groups concept.  This has to be built on top of them.

 > Cloning a window configuration will confuse those,
 > yes, but the point of the `window-id' suggestion is
 > that it makes those programs trivial to fix for
 > cloned configurations.

Cloning a window configuration is a separate issue because it will
create a copy of the original window.  The window property of an overlay
applies to the original window only and the question was whether that
window could be moved to another frame retaining its identity.

 >> Sort of.  My Emacs already does have considerable troubles fighting with
 >> wrapping menubars.  I don't use toolbars so I can't tell about them but
 >> IIRC there were a number of problems with wrapping toolbars.  Handling
 >> such bars with narrow frames might be quite challenging.
 >
 > If there are bugs in that area they ought to
 > be fixed anyway.

Yes, but that can take some time.  ISTR a bug where a wrapping menubar
caused the modeline to disappear.

 > By permitting icons to display and by letting
 > different parts of the bar be mouse sensitive
 > in different ways.  By having an option to generate
 > the format of the bar from keymaps rather than from
 > an explicit format string.

If someone writes that code we can continue discussing it.

 > Sounds like a bug.   It would be better if, given
 > only one column, the display-engine left the window
 > blank or (on graphical terminals) grey-ed out.

Maybe.  But you see some of the restrictions that apply.

 > The four child frames around the edge of a normal
 > frame, though - the four control panel areas - can
 > have a nil configuration.  When they do, they are
 > invisible, not reached by `next-frame', and don't
 > appear in the frame list.

So why have them exist at all?  One can always recreate them.

martin