From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: split-window-preferred-function Date: Wed, 02 Apr 2008 19:00:46 +0200 Message-ID: <47F3BBBE.4030007@gmx.at> References: <47E188D5.5030502@gmx.at> <87hcf1rrdj.fsf@jurta.org> <87r6e3k3hc.fsf@jurta.org> <87d4pfzt2j.fsf@jurta.org> <47ED4BF7.9060507@gmx.at> <871w5utnac.fsf@jurta.org> <47EE064A.1060105@gmx.at> <874papk8zl.fsf@jurta.org> <47F34982.2000706@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1207156217 30106 80.91.229.12 (2 Apr 2008 17:10:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Apr 2008 17:10:17 +0000 (UTC) Cc: Juri Linkov , rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 02 19:10:41 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jh6Tq-0005q1-I2 for ged-emacs-devel@m.gmane.org; Wed, 02 Apr 2008 19:10:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jh6TE-0004xn-3p for ged-emacs-devel@m.gmane.org; Wed, 02 Apr 2008 13:09:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jh6Oe-0006px-IL for emacs-devel@gnu.org; Wed, 02 Apr 2008 13:05:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jh6Od-0006p9-SA for emacs-devel@gnu.org; Wed, 02 Apr 2008 13:05:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jh6Od-0006oa-Mr for emacs-devel@gnu.org; Wed, 02 Apr 2008 13:05:11 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Jh6Oc-0000lA-8P for emacs-devel@gnu.org; Wed, 02 Apr 2008 13:05:10 -0400 Original-Received: (qmail invoked by alias); 02 Apr 2008 17:05:07 -0000 Original-Received: from 88-117-43-76.adsl.highway.telekom.at (EHLO [88.117.43.76]) [88.117.43.76] by mail.gmx.net (mp026) with SMTP; 02 Apr 2008 19:05:07 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18uHM8BvtEuMH0AA6EU6TeFWDvHThNN7ypmVxfRMt kdVjOijbWIDYld User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:94208 Archived-At: >>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.