[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: moving window handling into lisp
From: |
martin rudalics |
Subject: |
Re: moving window handling into lisp |
Date: |
Thu, 13 Aug 2009 20:07:58 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
>> 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.
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.
> 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?
martin
- Re: moving window handling into lisp, (continued)
- Re: moving window handling into lisp, martin rudalics, 2009/08/12
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/12
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/12
- Re: moving window handling into lisp, martin rudalics, 2009/08/13
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/13
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/13
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/13
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/13
- Re: moving window handling into lisp, martin rudalics, 2009/08/13
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/13
- Re: moving window handling into lisp,
martin rudalics <=
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/13
- Re: moving window handling into lisp, martin rudalics, 2009/08/14
- Re: moving window handling into lisp, Lennart Borgman, 2009/08/14
- Re: moving window handling into lisp, martin rudalics, 2009/08/14
- Re: moving window handling into lisp, martin rudalics, 2009/08/12
- Re: moving window handling into lisp, Stefan Monnier, 2009/08/12
- Re: moving window handling into lisp, martin rudalics, 2009/08/13
- Re: moving window handling into lisp, Stefan Monnier, 2009/08/13
- Re: moving window handling into lisp, martin rudalics, 2009/08/13
- Re: moving window handling into lisp, Stephen J. Turnbull, 2009/08/13