Re: moving window handling into lisp

[martin rudalics <rudalics@gmx.at>]

 >> The problem I see is with the "strategy" that sets the desired sizes.
 >> With 'eq-sizes you calculate them on the fly when you "walk down".
 >> Unfortunately, this won't help when you just want to enlarge one
 >> individual leaf window.  In that case we usually resize one adjacent
 >> window and leave the other windows alone.  You'd probably first set the
 >> min/max values of the window you want to enlarge to the desired value,
 >> relax the min/max values of an adjacent sibling and leave all other
 >> min/max values at the current sizes.  If this works out you're done.
 >>
 >> Otherwise, you'd have to relax min/max values for additional windows and
 >> see whether you succeed.  You'd probably start doing that process
 >> "inside out" by selecting siblings of the window you want to enlarge,
 >> siblings of their parent and so on.  That's what I meant with
 >> backtracking.  The complexity of that process is, in the worst case,
 >> proportional to the number of possible Emacs tilings of a frame into the
 >> windows you have.  Obviously, we don't expect the worst case to happen.
 >> But we'd probably need some reasonable divide-and-conquer strategy to
 >> make sure to always get a good result.  Finding such a strategy is the
 >> hard part.
 >
 > I am not sure why you want to do something like the above. However you
 > introduce a new element here: relaxing of the requirements.

Not only - in the first step I would make them stronger.

 > Do you really want to do that? Or did I misunderstand you?

When I change the size of a particular window on one end of my frame I
don't want Emacs to change the sizes of windows at the other end.
Changes should be "as local as possible".  For example, when I drag a
modeline I usually do not expect the sizes of windows not adjacent to
that modeline change unless Emacs has no other choice.

 > More seriously: if you are changing the rules, then please tell what
 > rules you want to use see we can see if the problem is solveable with
 > your new rules.

What rules?  Please tell me _how_ your algorithm would handle a single
`enlarge-window' command.  Which other windows would change in which
order?  How would new window sizes relate to the old ones?

martin