Re: moving window handling into lisp

[Lennart Borgman]

On Fri, Aug 14, 2009 at 9:18 AM, martin rudalics<address@hidden> wrote:

> None, if the adjacent subtree can handle the request.  All sorts of
> otherwise.  That's where the "temporary restrictions" you mention must
> be relaxed.


Ok. Could you please then summarize what rules you have thought of
here? What is it that should be relaxed? What do you want to happen
then? What problems do you see for different solutions there? (Not the
algorithms, just the rules, please.)


>> A very important idea in the algorithm is that it works with all the
>> child windows on level at once. You compute all the sizes on that
>> level and then you apply them. (So a new function in C for applying
>> the changes per sublevel is needed.)
>>
>> To apply enlarge-window (or any similar command)  -- or, VERY
>> important, rather what it does --- simply set fix size restrictions on
>> that windows size (to the desired size) and other windows (to their
>> current sizes) on that level that is not adjecent to the window that
>> we try to enlarge.
>>
>> If this fails then then take away the restrictions on windows
>> next-adjecent and try again. Repeat until success or final failure.
>> (The order of repetioins is just the lenght of the list, there is no
>> recursions, so it is no performance problem.)
>
> The recursion (or backtracking) is right with the "take away the
> restrictions on windows next-adjecent and try again".  It doesn't help
> if you remove that crucial detail from your algorithm and leave it to
> the caller to handle it.


Sorry, I must have expressed myself unclear in some way.

There is no recursion in my example above, just a simple iteration
when taking away the restrictions. One iteration for every sibling
window where you take away the restriction.

There is no "crucial details" left out. I just did not have time to
write an example of enlarge-window and left it to your imagination
here.

I will try to find some minutes in do write enlarge-window this way,
but it would help very much if you tried to summarize your views of
the restrictions. (As I already said above.)


> Applying the restrictions is trivial.  The point is in finding the right
> set of restrictions.


Yes. But finding a useful set of restrictions can't be done without
considering the structure of the code. And that is what I am trying to
do.

Without that you might get the impression that the problem is
np-complete while it is the structure of the current code that perhaps
(as I see it) is the problem instead.


>> Note: The existing enlarge-window should in this scenario go away and
>> a new one should be implemented (probably in elis then) that does the
>> above things. The same apply to the other window handling routines
>> that does similar things.
>
> As long as we can't at least emulate the present (poor) behavior ...

;-)

Doing it the way I suggest you can slightly change the rules so we can
avoid some of the troubles. But to show that we must get into some
more concrete exampel I guess. So please (again) tell me some example
of rules that you find troublesome.

You may have some very good point that I am totally missing. That will
show probably show up if we consider some more concrete example and
rules.


> martin
>