emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: moving window handling into lisp


From: Lennart Borgman
Subject: Re: moving window handling into lisp
Date: Tue, 11 Aug 2009 21:29:52 +0200

On Tue, Aug 11, 2009 at 9:16 PM, Stefan Monnier<address@hidden> wrote:
>>> Another approach is to have a transactional interface, like
>>> start-window-configuration and end-window-configuration:
>>> - during the transaction, windows can be resized to too-large/too-small
>>> sizes (but maybe window-fixed-size should stil be obeyed?).
>
>> This would still rely on some predictable behavior of `enlarge-window',
>> `adjust-window-trailing-edge' and `size_window'.
>
> There'd be new low-level functions to resize windows which would work in
> simple and predictable ways, but with the end-state being potentially
> invalid.
>
>> I suppose we should merge these functions into one Elisp function that
>> moves the trailing edge of a window and have one C function checking
>> whether the resulting window tree is well-formed and, if that is the
>> case, apply the change.
>
> As a "high-level" function, I'd imagine a function that looks like
> (window-resize W N) and returns the amount that it was able to resize
> (between 0 and N).
> It would work by calling itself recursively on siblings and/or children.
> It can't fail and cannot result in an invalid window-tree.


I promised Martin a recipe that I belive could avoid making the
problem np-complete. It is very simple, and maybe along the lines
Stefan is thinking. It is just like this:

Note: This recipe is for doing it logically, so "split" means a
logical thing in a logical tree. The actual window splitting is done
later after computation.

1) Make a logical representation of the window tree where you split as
necessary.
2) Walk this logical tree bottom up collecting minimum required window sizes.
3) Walk top bottom-wise applying the sizes as they could be.
4) Apply the splitting and the computed sizes to the window tree.

Step 3 could of course fail if the minimum sizes does not fit.
Step 4 should be know problem in itself (fi the needed primitives are
available of course).

I "forgot" taking some things into account above, perhaps.


Is the description of the algorithm structure clear? Am I
misunderstanding this, or?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]