Re: moving window handling into lisp

[Lennart Borgman <lennart.borgman@gmail.com>]

On Thu, Aug 13, 2009 at 3:56 PM, martin rudalics<rudalics@gmx.at> wrote:
>> This one is easier to play with.
> [...]
>>>> Here is the walking down part too. You have to tell me what you are
>>>> missing.
>
> When I try to evaluate that I get
>
> Window Root-1 is too small, min=9, but can be max=7

Yes, that how it should be. You evaluate this file to test. Look at
the bottom of the file.


> Anyway, I do hope to understand what you mean.  When "going up" you
> calculate minimum and maximum sizes and when "going down" you distribute
> the frame size recursively among its children according to some
> "strategy".  When the minimum and maximum sizes can't be applied you
> give up before going down.

Yes, you catch the errors going up before you try to apply.


> The problem I see is with the "strategy" that sets the desired sizes.
> With 'eq-sizes you calculate them on the fly when you "walk down".
> Unfortunately, this won't help when you just want to enlarge one
> individual leaf window.  In that case we usually resize one adjacent
> window and leave the other windows alone.  You'd probably first set the
> min/max values of the window you want to enlarge to the desired value,
> relax the min/max values of an adjacent sibling and leave all other
> min/max values at the current sizes.  If this works out you're done.
>
> Otherwise, you'd have to relax min/max values for additional windows and
> see whether you succeed.  You'd probably start doing that process
> "inside out" by selecting siblings of the window you want to enlarge,
> siblings of their parent and so on.  That's what I meant with
> backtracking.  The complexity of that process is, in the worst case,
> proportional to the number of possible Emacs tilings of a frame into the
> windows you have.  Obviously, we don't expect the worst case to happen.
> But we'd probably need some reasonable divide-and-conquer strategy to
> make sure to always get a good result.  Finding such a strategy is the
> hard part.

I am not sure why you want to do something like the above. However you
introduce a new element here: relaxing of the requirements.

Do you really want to do that? Or did I misunderstand you?

Of course, chaning the boundaries/requirement can lead to infinite
recursion.... ;-)

More seriously: if you are changing the rules, then please tell what
rules you want to use see we can see if the problem is solveable with
your new rules.

On the other hand, if you do not change the rules, then I can't see
why the algorithm I provided can't be used when you enlarge a single
window. But maybe you can, so please tell me.


> I suppose your approach would handle the case where you simply want to
> resize the containing frame.  Just calculate the min/max values and look
> whether the desired window sizes fit into that.  After that, adjust the
> windows arbitrarily with one line/column more or less.  But with
> frame-resizing the hard case is just that we need some heuristics when
> windows don't fit due to their hard min-weight/-height, fixed-size
> requirements.

If they do not fit, they do not fit. So you mean we should have new rules then?

Maybe. I am not sure. But if you please tell what rules you are
thinking of then I will try to put it into the algorithm (in case you
do not do it yourself, of course).


I could think of some rules to use, so it is not totally unfamiliar to
me. How about a rule like this:

- If the windows are too large then allow shrinking them to a system
wide default minimum size.

Such a rule could easily be added to the algorithm like this:

- run a first pass bottom-up.
- if it did not fit run a second bottom-up pass with the new rules.


> martin
>