Re: moving window handling into lisp

[martin rudalics]

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

We violently agree.  In particular the idea of temporarily binding
`window-min-height' to some small value and having the next resize
operation kill that window strikes me as quite flawed.

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

Agreed.  Honestly, do we need these variables?

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

It's easy to explain: When dragging a modeline, you probably want to
shrink/enlarge the bottom-most windows above the modeline and
enlarge/shrink the topmost windows below the modeline first.

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

Fine (but I don't recall if you participated in that discussion).

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

There's one small point here: The resizing function might know better
which window to delete.  WOW the function to pick the candidates for
deletion would probably walk the same windows anway.

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

But it wouldn't harm to consider this from the outset.

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

Not necessarily cheap.  But much, much simpler to code.

> Or we could use another algorithm
> which first figures out what the end tree should look like and then
> applies the changes, ...

That's what I had in mind.

martin