[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 02 Apr 2008 19:00:46 +0200
Mozilla Thunderbird 1.0 (Windows/20041206)
>>I'm not yet sure how to handle the following two:
>> || (NILP (XWINDOW (window)->parent))
> Wouldn't that be something like one-window-p ?
Probably, I haven't looked into this yet.
>> if (!NILP (XWINDOW (window)->prev))
>> other = upper = XWINDOW (window)->prev;
>> if (!NILP (XWINDOW (window)->next))
>> other = XWINDOW (window)->next, upper = window;
> This part of code needs a comment explaining what is the use of `upper'
> (i.e. why is enlarge_window called on `upper' rather than on `window'
> (or `other')).
Yes but I don't understand the rationale of this code. Maybe I find
something in the ChangeLogs. In any case, for horizontal splitting,
we'd have to do this for the left or right window too. I could call
`window-tree' and look if the windows have some common prefix in that
tree, but that appears very contrived, IMHO.
>>I initially planned to use `window-edges' to check whether two windows
>>are "arrayed" in some sense. That's not quite accurate when window
>>edges match but the involved windows have different parents. Hence
>>enlarge_window could affect other windows and the overall behavior of
>>`display-buffer' might change.
> Indeed, it's a problem. Maybe a good solution is to change the
> behavior: if you can't tell which if (next-window) is "->next" or not
> just by looking at window-edges, then the user probably can't either, so
> the current behavior (which depends on such a distinction) is not
> great anyway. Better would be to take all windows in a sequence of
> next-window/previous-window which (according to window-edges) are
> "siblings", and then rebalance them all.
IIUC `balance-windows-area' works on all windows only.
>>XEmacs handles this by exposing `window-parent', `window-next', ... to
>>Elisp. This would, however, contradict the Emacs ideology that Elisp
>>code should never see a non-leaf window. In particular, we would have
>>to rewrite things like `adjust-window-trailing-edge' which currently
>>chokes on non-leaf windows.
> Of course, we can also expose window-next without exposing
> window-parent, so we still only expose non-leaf windows.
I'm afraid not - `window-next' can name a non-leaf window.
Re: split-window-preferred-function, Stefan Monnier, 2008/04/02
Re: split-window-preferred-function, Juri Linkov, 2008/04/02
Re: split-window-preferred-function, Tassilo Horn, 2008/04/03
Re: split-window-preferred-function, Stefan Monnier, 2008/04/04
- Re: split-window-preferred-function,
martin rudalics <=