Re: Infrastructural complexity.

[martin rudalics]

>> Keybindings are not part of the window group concept but of ECB.  Emacs
>> without ECB (or some other UI) continues to work as if there were no
>> groups at all.
>
> I don't understand that answer.  In the edit-area
> of ECB I can display any buffer at all.  Aribtrary,
> existing code can run there.   That arbitrary code
> can call things like `window-list' only I don't
> see any right answer as to what window-list should
> return vis a vis the grouped windows in the display.

The return value of `window-list' must not be affected by running ECB.
If, for some reason, ECB wants to filter out windows not belonging to a
group it has to do that separately.  But what I meant in my answer was
that the semantics of functions like `other-window' or
`delete-other-windows' don't change wrt current Emacs unless you run a
UI like ECB in which case `delete-other-windows' will only delete other
windows in the same group and `other-window' will only switch to another
window in the same group.  This behavior must be built into the
functions `delete-other-windows' and `other-window' but can be triggered
only by activating a client like ECB before.

> That seems "weird".  For example, before the
> existence of window groups the list of windows
> returned by `window-list' always added up to
> a rectangle.   Looking at the list, you could
> predict what, say, `window-at' would do.

What makes you think it won't do that after adding window groups?

> After window groups, that implicit invariant is
> gone.  What exactly will that break in existing
> code?  I don't know - perhaps little or nothing
> or perhaps something.  It does break the conceptual
> simplicity of windows, though.

As I tried to say before, window groups are completely transparent wrt
existing code.  If you don't run a client like ECB you won't notice them
(unless I can abuse window groups to fix some other bugs).

> The very idea that an Elisp program could delete
> the edit area window seems dubious to me, not least
> in that how the window groups get resized in
> response seems necessarily arbitrary and not useful.

I don't understand this - please elaborate.

>> But they don't solve the window resizing issues either ;-)
>
> They do, actually.   Take that example again: killing
> the edit area window.   In the framelet proposal
> you simply can't do that because it would be a case of
> killing the sole ordinary window in a frame.

You can always kill the frame.

>>  > At no time, therefore, is there a need to change
>>  > the window property of overlays.
>
>> There is if we pretend that tearing off a window stands for "moving that
>> window from one frame to another".
>
> OK, and that might or might not be useful functionality
> to support but it is not what people mean by "tear-off"
> in the context of other GUI toolkits - so it is
> linguistically confusing.

I meanwhile understand that tearing off a window is not what you had in
mind when you talked about "tear-offs" ;-)

> OK.  I think it's just: (window-id WIN) / (set-window-id WIN VALUE)
> and a slightly more complicated conditional in the code that
> compares an overlay's `window' property to a given window.
>
> Then, of course, lots of elisp packages will stand in need
> of improvement to use ids rather than raw windows for the
> `window' property -- but that can be done incrementally.

Probably not many.  But we still don't solve the problem that
application programs temporarily store the identity of window just in
order to tell which window to use when one and the the same buffer is
simultaneously displayed in two or more windows.

> Do I correctly understand that the problem you
> are most worried about concerns toolbars, tabbars,
> and so forth in individual windows?

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 so, doesn't existing support for header lines
> already solve most of that problem?

How would header lines emulate menu or toolbars?

>> Just that the display-engine is not very good at displaying
>> 0-width/0-height objects.  The window code has special checks to avoid
>> that windows get too small.
>
> You wouldn't have 0-width AND 0-height.  For
> a detached vertical toolbar, 0-width.  For horizontal,
> 0-height.   This would be new to the display engine
> but it's not a huge new complexity - just a special
> rule for the case of a free-floating framelet.

FWIW, the display-engine already crashes when you give it a one-column
width window.

> Alternatively, it could be a frame with a nil window
> configuration which is also needed anyway for the four
> framelets that surround the main edit area.

How do you visually address a frame with a nil window configuration?
All I know about windows I can't see is that I usually forget about them
and that they show up when I need them least.

martin