Re: moving window handling into lisp

[martin rudalics <rudalics@gmx.at>]

 > You just have to find the window subtree that is adjecent to the
 > modeline and apply the algorithm there. (With new temporary
 > restrictions there. These things must of course be added to the
 > algorithm, but I can't see any fundamental problem with it.)
 >
 > What problems do you see with that?

None, if the adjacent subtree can handle the request.  All sorts of
otherwise.  That's where the "temporary restrictions" you mention must
be relaxed.

 > A very important idea in the algorithm is that it works with all the
 > child windows on level at once. You compute all the sizes on that
 > level and then you apply them. (So a new function in C for applying
 > the changes per sublevel is needed.)
 >
 > To apply enlarge-window (or any similar command)  -- or, VERY
 > important, rather what it does --- simply set fix size restrictions on
 > that windows size (to the desired size) and other windows (to their
 > current sizes) on that level that is not adjecent to the window that
 > we try to enlarge.
 >
 > If this fails then then take away the restrictions on windows
 > next-adjecent and try again. Repeat until success or final failure.
 > (The order of repetioins is just the lenght of the list, there is no
 > recursions, so it is no performance problem.)

The recursion (or backtracking) is right with the "take away the
restrictions on windows next-adjecent and try again".  It doesn't help
if you remove that crucial detail from your algorithm and leave it to
the caller to handle it.

 > Of course I did not implement an easy way to apply the restrictions
 > right now but that is easily added (except for my clumsiness... ;-).

Applying the restrictions is trivial.  The point is in finding the right
set of restrictions.  Compare how modeline dragging is done in Emacs 21
and Emacs 22.  The differences show up come because Emacs 22 does not
relax the respective restrictions.  OTOH relaxing them got us into all
sorts of troubles in Emacs 21.

 > Note: The existing enlarge-window should in this scenario go away and
 > a new one should be implemented (probably in elis then) that does the
 > above things. The same apply to the other window handling routines
 > that does similar things.

As long as we can't at least emulate the present (poor) behavior ...

martin