Re: moving window handling into lisp

[martin rudalics]

>> Wasn't that something you wanted to avoid?
>
> No.  I did mention that its use to resurrect a deleted window should be
> avoided because it may not work any more at some point in the future.
> But we're here only talking about resizing windows, no deletion.

Deleting windows currently is an inherent part of resizing, otherwise
`window-min-height' and `window-min-width' wouldn't make sense.  Where
and how would you handle these variables?

>> For modeline dragging we need a function which resizes a window by
>> moving _one edge_ only (which can be either the leading or the trailing
>> one).  If, in addition, we want to call that function recursively we
>> must be able to specify _which edge_ it should move, that is, it must be
>> able to move trailing _and_ leading edges.
>
> Yes, that'd probably be a different function from the one I suggested,
> tho it could/would probably use the one I suggested for part of its work.

That functionality was important enough to blow up the argument list of
size_window.  And that's the function we want to replace, I suppose?

>> Moreover, we probably want
>> to specify whether the function is allowed to delete windows, resize
>> windows below `window-min-height' or `window-min-width', or ignore the
>> value of `window-size-fixed'.
>
> At the user-level, it's pretty clear: no function resizing should ever
> delete a window, resize a window below window-min-height or
> window-min-width or ignore window-size-fixed.

I recall a discussion where everyone but me insisted that resizing
_should_ delete windows that get to small.  So I'm getting confused
about what "user-level" stands for.

Anyway, we may have to call some such function when resizing a frame and
that may ultimately require to delete windows.  Do you want to delegate
that to a higher level and re-call our function?

>> Also I think that a call with N > 1 failing to resize the window should
>> be able to result in an abort.
>
> It's easy to provide that behavior from outside when needed.

If window-configuration handling stuff is done within the function you
have in mind, then there will be two identic configurations we have to
save at the same time.  Why waste that space?

>> An application that can't get a window of the appropriate size might
>> prefer to use a new frame and leave the original configuration
>> unchanged.  Should it do that by saving the window configuration and
>> restoring it provided the amount returned by `window-resize' doesn't
>> fit its needs?
>
> Yes, it could.

Expensive as explained above.

>>> ... on siblings and/or children.
>> Including siblings of the window's parent, grandparent, ... I suppose.
>
> That is the tricky part of th algorithm, indeed.
>
>>> It can't fail and cannot result in an invalid window-tree.
>> IMO `window-resize' should be written in Elisp while the check whether a
>> window tree is invalid would reside in C to guarantee that Elisp code
>> never crashes Emacs.
>
> Yes, it's part of my working assumption.

So we agree on two points, at l(e)ast ;-)

martin