[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: Wed, 12 Aug 2009 10:56:56 +0200
User-agent: Thunderbird (Windows/20090302)

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

And how'd we revert to a valid state?  Using `set-window-configuration'?
Wasn't that something you wanted to avoid?

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

For modeline dragging we need a function which resizes a window by
moving _one edge_ only (which can be either the leading or the trailing
one).  If, in addition, we want to call that function recursively we
must be able to specify _which edge_ it should move, that is, it must be
able to move trailing _and_ leading edges.  Moreover, we probably want
to specify whether the function is allowed to delete windows, resize
windows below `window-min-height' or `window-min-width', or ignore the
value of `window-size-fixed'.

Also I think that a call with N > 1 failing to resize the window should
be able to result in an abort.  An application that can't get a window
of the appropriate size might prefer to use a new frame and leave the
original configuration unchanged.  Should it do that by saving the
window configuration and restoring it provided the amount returned by
`window-resize' doesn't fit its needs?

> ... on siblings and/or children.

Including siblings of the window's parent, grandparent, ... I suppose.

> It can't fail and cannot result in an invalid window-tree.

IMO `window-resize' should be written in Elisp while the check whether a
window tree is invalid would reside in C to guarantee that Elisp code
never crashes Emacs.  I'm not sure about the interface though.  I
imagine primitives like say `book-window-parent', `book-window-top',
`book-window-lines', ... and have a function checking-in the booked
values by (1) checking whether the booked values form a valid window
tree and, if that is the case, (2) replacing the actual values by the
booked values.


reply via email to

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