From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: split-window-preferred-function Date: Wed, 02 Apr 2008 11:18:26 -0400 Message-ID: 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=us-ascii X-Trace: ger.gmane.org 1207149543 2730 80.91.229.12 (2 Apr 2008 15:19:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Apr 2008 15:19:03 +0000 (UTC) Cc: Juri Linkov , rms@gnu.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 02 17:19:24 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 1Jh4k6-0007Cz-Jl for ged-emacs-devel@m.gmane.org; Wed, 02 Apr 2008 17:19:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jh4jU-0000RK-6V for ged-emacs-devel@m.gmane.org; Wed, 02 Apr 2008 11:18:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jh4jR-0000R5-IC for emacs-devel@gnu.org; Wed, 02 Apr 2008 11:18:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jh4jP-0000QQ-HL for emacs-devel@gnu.org; Wed, 02 Apr 2008 11:18:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jh4jP-0000QM-BB for emacs-devel@gnu.org; Wed, 02 Apr 2008 11:18:31 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182] helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jh4jL-0002nx-6n; Wed, 02 Apr 2008 11:18:27 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAP9A80dMCrUE/2dsb2JhbACBWqp1 X-IronPort-AV: E=Sophos;i="4.25,594,1199682000"; d="scan'208";a="17448950" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 02 Apr 2008 11:18:26 -0400 Original-Received: from pastel.home ([76.10.181.4]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id ITU48426; Wed, 02 Apr 2008 11:18:26 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 1F9C07FE2; Wed, 2 Apr 2008 11:18:26 -0400 (EDT) In-Reply-To: <47F34982.2000706@gmx.at> (martin rudalics's message of "Wed, 02 Apr 2008 10:53:22 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) 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:94202 Archived-At: >> 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