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: display-buffer-change Date: Sun, 09 Sep 2007 15:33:19 -0400 Message-ID: References: <200708271732.22306.zslevin@gmail.com> <46DD9F41.8090700@gmx.at> <46DE63EE.3070509@gmx.at> <87wsv4fvav.fsf@stupidchicken.com> <46DFC3AE.3020009@gmx.at> <46E0136F.6080602@gmx.at> <46E06C5B.80408@gmx.at> <46E198D8.8080507@gmx.at> <46E269E6.6090305@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189368275 29905 80.91.229.12 (9 Sep 2007 20:04:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2007 20:04:35 +0000 (UTC) Cc: David =?iso-8859-1?Q?K=3Fgedal?= , rms@gnu.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 10 06:04:22 2007 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 1IUa1Z-0008CP-TV for ged-emacs-devel@m.gmane.org; Mon, 10 Sep 2007 05:33:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUSXC-0001pV-0x for ged-emacs-devel@m.gmane.org; Sun, 09 Sep 2007 15:33:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUSX8-0001pG-Un for emacs-devel@gnu.org; Sun, 09 Sep 2007 15:33:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUSX7-0001od-3M for emacs-devel@gnu.org; Sun, 09 Sep 2007 15:33:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUSX6-0001oK-SG for emacs-devel@gnu.org; Sun, 09 Sep 2007 15:33:24 -0400 Original-Received: from tomts16.bellnexxia.net ([209.226.175.4] helo=tomts16-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUSX3-0006Y4-84; Sun, 09 Sep 2007 15:33:21 -0400 Original-Received: from pastel.home ([70.55.141.227]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070909193319.ZWZE574.tomts16-srv.bellnexxia.net@pastel.home>; Sun, 9 Sep 2007 15:33:19 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 308F28072; Sun, 9 Sep 2007 15:33:18 -0400 (EDT) In-Reply-To: <46E269E6.6090305@gmx.at> (martin rudalics's message of "Sat\, 08 Sep 2007 11\:22\:46 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-Detected-Kernel: Solaris 8 (1) 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:78326 Archived-At: >> I guess I see the following problems: >> 0 - it's not clear to me why Emacs chooses to split B rather than A. >> It seems unrelated to the split-height-threshold fix, so we need to look >> into this before being able to determine how best to fix it. > Fget_largest_window returns the largest window and B could be that > window. So it's not always going to behave this way, it depends on details of the current layout. A shift by 1 line can change the result? >> 1 - since we're in buffer/window A, it would probably be preferable to place >> buffer C closer rather than further, so in this case after splitting B >> display-buffer should prefer using the top window for C and the bottom >> one for B. > With `split-window' the new window is the lower one, we would lose all > associations for B if we did that. I know. It'a problem. Independent from the current one. >> 2 - "dedicated" is mostly meant to cause deletion of the buffer to also >> cause deletion of the window. It says nothing about the window having >> a fixed size or being non-splittable. > Agreed. >> 3 - we have window-size-fixed for that. > David: Could you set that for the buffer of your window B and look > whether it gives good results. I don't think that's going to help. This variable is almost never used/obeyed :-( And I don't think it'd help the OP anyway because he doesn't want to go a configure such things. And the window shouldn't be fixed-size anyway (you should still be able to resize it with balance-window, for example). >> 4 - we don't have window-(un)splittable for that (there's a frame parameter >> to prevent splitting windows in that frame, tho). > Earlier I thought about splitting obey a buffer-local value for > `split-height-threshold'. That would make a lot of sense. But I don't think it'd help the OP either because it's too detailed a configuration. To get back to the OP's example scenario, starting from >>>+-------------+ >>>| | >>>| A | >>>| | >>>+-------------+ >>>| | >>>| B | >>>| | >>>+-------------+ Why would >>>+-------------+ >>>| A | >>>+-------------+ >>>| C | >>>+-------------+ >>>| | >>>| B | >>>| | >>>+-------------+ be better than >>>+-------------+ >>>| | >>>| A | >>>| | >>>+-------------+ >>>| B | >>>+-------------+ >>>| C | >>>+-------------+ and why should it depend on B being dedicated? Stefan