Re: moving window handling into lisp

[martin rudalics <rudalics@gmx.at>]

 > There are some ideas here that are rather similar but differs a bit.
 > You and Stefan have been talking about the idea about treating the
 > size changes as transactions with possible roll back.
 >
 > That seems ok to me. But I choosed a little bit different route. I am
 > trying to make the calculations first and only apply them if new sizes
 > fit.

That's fine.  But it won't harm to check twice whether the sizes really
fit.

 > However with my idea there is still the problem of applying the
 > new sizes without bumping into any restriction during the applying
 > phase. This could happen even if you know that the final result will
 > fit.
 >
 > That was the reason I asked for a function above to set the sizes of
 > all children at once. But such a function will not help since bumbing
 > into restrictions can happen further down the tree also.
 >
 > So what I need is still a way to apply the new sizes without
 > restriction checks during that phase. Am I clear enough when I try to
 > explain this? How should I do to avoid the restrictions in this phase?

What problems do you have doing your calculations using copies of the
original sizes?  We can initialize these with the current values and
retrieve via `window-new-height' and `window-new-width'.

 > Yes, I know that this is lacking. I have been wondering about this
 > part. It is not clear to me how resizing and deletion/creation of
 > windows are tighed together in the current code. I think those parts
 > should be broken up.

It's not entirely trivial to do that.  Resizing during window deletion
must succeed, at least in a second attempt.  So if we want to do this in
Elisp we must be able to resize fixed-size windows and never issue a
failure.

 > Can you please try to explain how things are now
 > and if you see some way to brake those things apart?

I explained that in another post:

- `delete_window' resizes either the sibling above or below W and is not
   allowed to delete other windows.  So inherently `delete_window' is not
   able to handle fixed-size windows correctly even if size_window were.

To handle fixed-size windows "more" correctly `delete_window' should be
able to operate on all windows.  Obviously, in a two-window case with
the only other window fixed-size we have to resize that other window.

 > Then I assume that window configurations must be used to get my
 > suggestion to work. The drawback I see then is that window pointers
 > migh gets lost. Are there any way around that?

Which window pointers get lost?

 > I am sorry, but I can't see why that should make it harder to
 > understand. The text to show can of course be changed to avoid some
 > confusion. Does not that help?

Like "you can restore the previous configuration within a suitable
frame-size" by hitting ...  Maybe.  Let's add it to the set of possible
solutions.

 >>>> You do undelete all the time.  It's completely transparent.
 >>> How can it be transparent if windows disappears and reappears? I must
 >>> be misunderstanding you somehow...
 >> There might be no redisplay in between.
 >
 > How can you avoid that when the frame gets too small?

`adjust-window-trailing-edge' can temporarily delete a window and
resurrect it without the user noticing because there's no redisplay in
between.  When you program in Elisp you can try to inhibit redisplay but
I would not recommend that.  In any case, I don't understand how this
should relate to frames getting to small.

 >> In many applications (Thunderbird is one of them) I can make subwindows
 >> disappear completely by dragging one of their borders and make them
 >> reappear later by dragging on the border where they disappeared.
 >
 > Are there no sign at all that there are 0-size windows there?

Thunderbird leaves a horizontal divider behind.

martin