Re: split-window-preferred-function

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

> and

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

> 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