Re: Infrastructural complexity.

[Thomas Lord]

On Wed, 2009-07-22 at 12:12 +0200, martin rudalics wrote:

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


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

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



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


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.


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

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.  

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.


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

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





>  >>  > 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" ;-)

Yup.


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

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.


>  > 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 there are bugs in that area they ought to
be fixed anyway.


>  > If so, doesn't existing support for header lines
>  > already solve most of that problem?
> 
> How would header lines emulate menu or toolbars?

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.



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

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.


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

I retract the idea of a nil window configuration
for tear-off windows - that's a mistake.

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.

-t





> 
> martin