Re: Infrastructural complexity.

[Thomas Lord <lord@emf.net>]

On Tue, 2009-07-21 at 19:25 +0200, martin rudalics wrote:
> > I'm pretty concerned about the impact window groups
>  > have on existing abstractions.
> 
> None, hopefully.
> 
>  > For example, if groups
>  > are used as "control panels" then they probably should
>  > not be reachable by C-x o;  `next-frame' is more appropriate.
> 
> 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.




>  > I'm not sure there is a good answer to whether or not window
>  > group windows should appear in the return value of `buffer-list'.
> 
> You mean `window-list'? 

Yes.  Sorry.

>  They won't appear there because this function
> returns only life windows.  There would be an extra function that gets
> you all active window groups.

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.

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.




>  > I don't think window groups should resize the same way as
>  > non-grouped windows when a non-group window is deleted.
>  > I think the presence of window groups will make it more
>  > difficult to improve the window configuration code.

> Resizing windows must be rethought anyway.  Fortunately, window groups
> do not add any additional complexity here.  Emacs worked with leaking
> internal windows for quite some time.

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.



>  > Framelets have none of those problems.

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



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



>  > Saving and restoring window configurations is a separate
>  > question entirely.   The "window property problem" does
>  > come up again there, I guess.  Perhaps the solution for
>  > that is to allow windows to have an "ID" slot which may be
>  > bound to a symbol, and allow the window property of an
>  > overlay to be a symbol which may or may not mach the vale
>  > of "ID".

> This could work indeed, as well as some other form of aliases.  But I
> don't want to think of specifying that.

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.


>  > Suppose that every frame and every Emacs window had (optional)
>  > menu, toolbar, and tabbar lines.  These can be understood as
>  > all variations on the same thing: they are a GUI interface to
>  > current keymaps.   These optional lines could be on any of the
>  > four edges of the window or frame.

> Unfortunately bars are not lines, they vary in size and shape and create
> all sorts of troubles for the display-engine.

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

If so, doesn't existing support for header lines
already solve most of that problem?


>  > Then a natural way to have "separate" forms of those is to
>  > permit the creation of a detached framelet (a frame with
>  > non-nil parent) and permit it to contain a single, 0-width
>  > or 0-height Emacs window - so that the menu, tab, or tool-bar
>  > is the only thing visible.
> 
> 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.


>  > As a side effect of that design there would be a neat
>  > feature possible:  the 0-width or -height window could
>  > be made non-0 width/height for the purpose of displaying
>  > help text.   For example, typing C-h k and then mouse-clicking
>  > on a toolbar icon could temporarily expand the invisible
>  > window (making it visible) and put the help text there.
> 
> I'm afraid I'll have to add 0-size windows to the list of objects that
> require a frame-based solution.

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.

-t