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: window-size constraints (was: bug#410: 23.0.60; display-buffer regression) Date: Sat, 14 Jun 2008 11:31:14 -0400 Message-ID: References: <873anhkn4m.fsf@escher.local.home> <4853920E.9020106@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1213457489 1394 80.91.229.12 (14 Jun 2008 15:31:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2008 15:31:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 14 17:32:13 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 1K7Xjg-0002pw-L8 for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 17:32:12 +0200 Original-Received: from localhost ([127.0.0.1]:43734 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7Xis-00048I-Hg for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 11:31:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7Xim-00045t-VR for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:31:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7Xim-00044R-24 for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:31:16 -0400 Original-Received: from [199.232.76.173] (port=42946 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7Xil-000440-Ss for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:31:15 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:17466) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K7Xil-0008MW-0h for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:31:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFANeAU0jO+KWv/2dsb2JhbACBW6sX X-IronPort-AV: E=Sophos;i="4.27,644,1204520400"; d="scan'208";a="22519269" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 14 Jun 2008 11:31:14 -0400 Original-Received: from pastel.home ([206.248.165.175]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id UVT64014; Sat, 14 Jun 2008 11:31:14 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 44F8F8336; Sat, 14 Jun 2008 11:31:14 -0400 (EDT) In-Reply-To: <4853920E.9020106@gmx.at> (martin rudalics's message of "Sat, 14 Jun 2008 11:40:30 +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:99174 Archived-At: > I'd like to make the window code resilient in a way that applications > like calendar can naturally set `window-size-fixed'. As a consequence, > `display-buffer' wouldn't change the calendar window's size even it were > larger than the new window. Setting `window-size-fixed' can currently > result in unexpected behavior. Fixing this is non-trivial. > Also I'd like to give `split-height-threshold' and `window-min-height' > buffer-local semantics and maybe add a `window-max-height' variable so > to do `fit-window-to-buffer' and `shrink-window-if-larger-than-buffer' > implicitly during each window configuration change. `window-min-height' > equalling `window-max-height' for a particular buffer would then imply > `window-size-fixed' for that buffer. > Eventually, a user should be able to change window configurations > arbitrarily with the calendar window always keeping its original size > (unless there's no other way, obviously). I think we should go in the direction of "constraints", which would take the form of Elisp functions. Every configuration change would correspond to adding&removing constraints, and then try and solve the resulting CSP. Constraints would come with priorities so that in the case the CSP has no solution, we can choose which constraint(s) to break, or alternatively, the satisfaction of a constraint would not be boolean, so the goal would be to try and maximize the satisfaction. While writing the balance-window-area code, I went through several iterations, and some of them just tried to move window-boundaries in arbitrary ways, then measure the "balance-factor" (basically, the window-area variance) and little by little move towards a local optimium. Also, I have some uninstalled code that uses window-configuration-change-hook to preserve the `balance-window-area'ness of a frame when windows are created/deleted. Stefan