Re: moving window handling into lisp

[martin rudalics <rudalics@gmx.at>]

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