On Thu, Aug 13, 2009 at 8:07 PM, martin rudalics<rudalics@gmx.at> wrote:

>> I am not sure why you want to do something like the above. However you
>> introduce a new element here: relaxing of the requirements.
>
> Not only - in the first step I would make them stronger.
>
>> Do you really want to do that? Or did I misunderstand you?
>
> When I change the size of a particular window on one end of my frame I
> don't want Emacs to change the sizes of windows at the other end.
> Changes should be "as local as possible".  For example, when I drag a
> modeline I usually do not expect the sizes of windows not adjacent to
> that modeline change unless Emacs has no other choice.

I see. But would not that be easy to implement with the algorithm I suggested?

You just have to find the window subtree that is adjecent to the
modeline and apply the algorithm there. (With new temporary
restrictions there. These things must of course be added to the
algorithm, but I can't see any fundamental problem with it.)

What problems do you see with that?


>> 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.
>
> What rules?  Please tell me _how_ your algorithm would handle a single
> `enlarge-window' command.  Which other windows would change in which
> order?  How would new window sizes relate to the old ones?


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

Of course I did not implement an easy way to apply the restrictions
right now but that is easily added (except for my clumsiness... ;-).


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.



I attach yet a new version of my little play thing for this. I have
not tried to implement something that handles restrictions as per
above there. You could at the moment simulate it by setting the
restrictions for max and min sizes for a window. It is not difficult
to add the restrictions, it just one of those small things where I
tend to make a lot of small mistakes a la or/and etc so I do not want
to do it right now. I need some more minutes to get it done. (What I
have done in this version is making it a bit easier to play with and
added comments about how I think it should tie into the C level.)


> martin
>