[Top][All Lists]

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

Re: split-window-preferred-function

From: martin rudalics
Subject: Re: split-window-preferred-function
Date: Wed, 02 Apr 2008 19:00:46 +0200
User-agent: 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.

reply via email to

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