From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?David_K=C3=A5gedal?= Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-change Date: Mon, 10 Sep 2007 08:48:39 +0200 Message-ID: <87zlzvxbg8.fsf@morpheus.local> 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1189428681 19746 80.91.229.12 (10 Sep 2007 12:51:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 10 Sep 2007 12:51:21 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier , martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 10 22:51:08 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 1IUpCG-0000Fm-29 for ged-emacs-devel@m.gmane.org; Mon, 10 Sep 2007 21:45:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUhht-0003W9-9K for ged-emacs-devel@m.gmane.org; Mon, 10 Sep 2007 07:45:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUdkv-0005GA-KZ for emacs-devel@gnu.org; Mon, 10 Sep 2007 03:32:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUdku-0005Fc-4D for emacs-devel@gnu.org; Mon, 10 Sep 2007 03:32:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUdku-0005FY-0Z for emacs-devel@gnu.org; Mon, 10 Sep 2007 03:32:24 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IUdkp-000737-Os; Mon, 10 Sep 2007 03:32:19 -0400 Original-Received: from mail.lysator.liu.se ([130.236.254.3]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUdVt-0006OL-KZ; Mon, 10 Sep 2007 03:16:53 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BF3A6200A1EC; Mon, 10 Sep 2007 08:48:48 +0200 (CEST) Original-Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21184-01-53; Mon, 10 Sep 2007 08:48:47 +0200 (CEST) Original-Received: from morpheus (c83-253-22-183.bredband.comhem.se [83.253.22.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id F11C6200A1E2; Mon, 10 Sep 2007 08:48:46 +0200 (CEST) Original-Received: by morpheus (Postfix, from userid 1000) id 96355BFA56; Mon, 10 Sep 2007 08:48:39 +0200 (CEST) In-Reply-To: <46E269E6.6090305@gmx.at> (martin rudalics's message of "Sat, 08 Sep 2007 11:22:46 +0200") User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (gnu/linux) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-Detected-Kernel: Linux 2.6, seldom 2.4 (older, 4) X-Mailman-Approved-At: Mon, 10 Sep 2007 07:44:37 -0400 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:78432 Archived-At: martin rudalics writes: > Stefan Monnier schrieb: >>>>I must have lost too much context: I do not understand the >>>>above description. Can someone spell it out in baby-steps for my poor >>>>excuse for a brain? >> >> >>>The OP explained it as follows: >> >> >>>>Split an emacs frame in two windows showing buffers A and B: >>>> >>>>+-------------+ >>>>| | >>>>| A | >>>>| | >>>>+-------------+ >>>>| | >>>>| B | >>>>| | >>>>+-------------+ >>>> >>>>While in the lower window, run >>>> >>>>(set-window-dedicated-p (selected-window) t) >>>> >>>>Now, in the upper window, run >>>> >>>>(display-buffer "C") >>>> >>>>In Emacs 21, this will be the result: >>>> >>>>+-------------+ >>>>| A | >>>>+-------------+ >>>>| C | >>>>+-------------+ >>>>| | >>>>| B | >>>>| | >>>>+-------------+ Actually, I think that the size of B is diminished somewhat sometimes. >>>>In Emacs 22, this will be the result: >>>> >>>>+-------------+ >>>>| | >>>>| C | >>>>| | >>>>+-------------+ >>>>| | >>>>| B | >>>>| | >>>>+-------------+ >>>> >>>>In Emacs 22 with split-heigh-threshold=3D10, this will be the result: >>>> >>>>+-------------+ >>>>| | >>>>| A | >>>>| | >>>>+-------------+ >>>>| B | >>>>+-------------+ >>>>| C | >>>>+-------------+ >>>> >> >> >>>What he apparently wants is window B always display the same buffer, stay >>>below all other windows, and not change its size. >> >> >> 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. > >> 1 - since we're in buffer/window A, it would probably be preferable to p= lace >> 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 bott= om >> one for B. > > With `split-window' the new window is the lower one, we would lose all > associations for B if we did that. > > >> 2 - "dedicated" is mostly meant to cause deletion of the buffer to also >> cause deletion of the window. It says nothing about the window havi= ng >> a fixed size or being non-splittable. > > Agreed. Having a fixed size is not important for me. The most important property for me is that it remains being fixed at the bottom of the frame. This seemed to hold in Emacs 21, which made me happy. But it might have been unintended. >> 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. No, it gives me an error: "Attempt to split fixed-size window". I think the (short) instructions at the top should be enough for you to reproduce it as well. >> 4 - we don't have window-(un)splittable for that (there's a frame parame= ter >> to prevent splitting windows in that frame, tho). > > Earlier I thought about splitting obey a buffer-local value for > `split-height-threshold'. > --=20 David K=C3=A5gedal