Re: moving window handling into lisp

[Stefan Monnier]

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

"currently" is the operative word.  I consider it to be a serious flaw
in the current design.

> otherwise `window-min-height' and `window-min-width' wouldn't make
> sense.  Where and how would you handle these variables?

They would cause the window resizing to fail.  I would only consider
deleting too-small windows when faced with a frame-resize, where failure
would be worse.

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

Could be.  I haven't spent enough time looking at the code yet.

> I recall a discussion where everyone but me insisted that resizing
> _should_ delete windows that get to small.

If I did insist on that back then, I was wrong.  Luckily, I forgot about
having such a bad idea.

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

Yes.

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

Maybe we'll decide to provide the feature directly from within, if
performance forces us to.  We're sufficiently far from an implementation
that I have no idea why you'd bring up such issues at this point.

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

Could be.  I wouldn't bet on it, tho.  If needed, we could even make the
window tree objects a bit more functional, in which case save/restore
a window tree becomes very cheap.  Or we could use another algorithm
which first figures out what the end tree should look like and then
applies the changes, ...


        Stefan