[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 02 Apr 2008 11:18:26 -0400
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
>> This change could involve exposing whatever else is needed.
> I'm not yet sure how to handle the following two:
> || (NILP (XWINDOW (window)->parent))
Wouldn't that be something like one-window-p ?
> 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'
> 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.
> 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.
Stefan Monnier <=
Re: split-window-preferred-function, Juri Linkov, 2008/04/02
Re: split-window-preferred-function, Tassilo Horn, 2008/04/03