Re: Infrastructural complexity.

[Thomas Lord]

On Mon, 2009-07-27 at 08:40 +0200, martin rudalics wrote:

> `next-window' has a MINIBUF and an ALL-FRAMES argument.  I'm not sure
> whether and how their semantics would change with nested frames.

Ok.  One interesting case might be `compare-windows', 
as follows:

* Current behavior

  I've two visible frames, one window each - I run
  `compare-windows'.  The comparison will be
  between the two windows in the visible frames.

* After behavior

  With no changes to `next-window', assume that 
  I have two frames.  In each frame there is but
  one edit-area window.  However, the selected frame
  also has a visible control panel frame.  One of
  the two visible edit areas is the current window.
  Depending on where in the frame list the 
  control panel is, `compare-windows' might compare
  the two edit area windows or it might compare an
  edit area window to a control panel window.

At first glance, that sounds bad and, in that sense,
you have a good point.  Where I think you're off is
in the notion to fix that by changing `next-window'.

The problem is that sometimes it will be The Right
Thing to compare the two edit area windows and other
times it will be TRT to compare an edit area window
with a control panel window.  It really depends on
what the user wants to do and on what is displayed
in each window.

The order of windows per `next-window' can't 
depend on "what the user means when invoking
the current command".   That is why `compare-windows'
already contains two calls to `next-window'
with various parameters.  It calls `next-window'
one way and finds out if the result "makes sense"
for the `compare-windows' function.  If not, it
tries calling `next-window' a different way and
again checks if the result "makes sense".

My conclusion is that IF users are unhappy with
what `compare-windows' does after control panels
are introduced, then it is `compare-windows'
rather than `next-window' that has to change.
And that's a big IF, it's not a forgone conclusion
that people will be unhappy with the interaction
of control panels and the existing `compare-windows'
code.  Note that nothing about "framelets" vs. 
"window groups" changes this conclusion: with EITHER
approach, the question of whether and how to 
modify the window-selection logic in `compare-windows'
still comes up.

Another function with similar issues would be
`server-switch-buffer'.  If the default logic
for selecting a window in which to display the
buffer requested via the server returns a 
minibuffer window, `next-window' is used 
to find a better window.   It is conceivable
that it might wind up picking a control
panel window when an edit area window is
more desirable.  (Equally conceivable that
a control panel window might be more desirable.)
However, the existing logic in `server-switch-buffer'
to honor `window-dedicated-p' looks as if it
would handle this case properly, provided that
programs `set-window-dedicated' for control 
panel windows that shouldn't be casually re-used.

In any event, there is no single change to 
`next-window' that would DTRT for all cases
of either `compare-windows' or `server-switch-buffer'
and no change to `next-window' that would be 
right for both functions.   It looks more like
IF, in practice, the default behaviors of those
functions have to change then the logic in those
functions themselves has to change.

>  >>  > Maybe.  There are other possibilities.
>  >>  > It could also be done with something like
>  >>  > the layout engines found in some GUI
>  >>  > toolkits.
>  >>
>  >> These would have to be rewritten and adapted accordingly.
>  >
>  > It shouldn't be very much code.
> 
> Fine.  This might also help frame resizing code DTRT in general.

I'm not sure what problem with frame resizing
you are referring to but, ok.

> Maybe it would be simpler to call framelets just frames and the "outer"
> (nil-parent) frame something different so there would be no changes in
> the naming conventions.

I don't want to confuse this immediate discussion
with new names for the same thing but...

I would say they are all simply "frames".  

Perhaps a good name for a frame with a nil
parent is a "primary frame".   One with a 
non-nil parent is an "attached frame".

(frame-p a-primary-frame) => t
(frame-p an-attached-frame) => t

(frame-attached-p primary) => nil
(frame-attached-p attached) => a-primary-frame

Analogous to `window-dedicated-p' but
with no corresponding `set-*' function
(yet?).

-t