Re: moving window handling into lisp

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> There'd be new low-level functions to resize windows which would work in
>> simple and predictable ways, but with the end-state being potentially
>> invalid.

> And how'd we revert to a valid state?  Using `set-window-configuration'?

The concept of transaction says that wehn you reach the end, you check
that things went right and if they don't you revert to the start state.
So yes, obviously it'd internally use something similar to
set-window-configuration.

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

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

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

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

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

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


        Stefan