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: FW: fit-frame.el Date: Tue, 11 Mar 2008 14:17:48 -0400 Message-ID: References: <004301c88269$637220e0$0600a8c0@us.oracle.com> <000f01c882d0$df847ef0$c2b22382@us.oracle.com> <002c01c882ef$a76bbeb0$c2b22382@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205259518 15872 80.91.229.12 (11 Mar 2008 18:18:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Mar 2008 18:18:38 +0000 (UTC) Cc: 'Emacs-Devel' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 11 19:19:02 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 1JZ93s-0005w9-P0 for ged-emacs-devel@m.gmane.org; Tue, 11 Mar 2008 19:18:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZ93K-0004Ld-4r for ged-emacs-devel@m.gmane.org; Tue, 11 Mar 2008 14:18:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZ93G-0004Jx-7M for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:18:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZ93B-0004Jg-E9 for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:18:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZ93B-0004JX-Ak for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:18:09 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JZ93B-0003VA-1W for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:18:09 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id B06892CF9EB; Tue, 11 Mar 2008 14:18:08 -0400 (EDT) Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 04E763FE0; Tue, 11 Mar 2008 14:17:49 -0400 (EDT) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id E21836CAA2; Tue, 11 Mar 2008 14:17:48 -0400 (EDT) In-Reply-To: <002c01c882ef$a76bbeb0$c2b22382@us.oracle.com> (Drew Adams's message of "Mon, 10 Mar 2008 12:45:19 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:92171 Archived-At: >> but it's far from clear what might be meant by "fit a frame to the >> current buffer" (unless the current buffer is the only one >> shown in the frame, that is). > What is meant by "fit a frame to the current buffer" is detailed in the doc > string, starting with "_Fitting a non-empty buffer means_ resizing the frame > to the smallest size such that the following are both true:". This description is an algorithm, i.e. code written in English. Most people are poor at reading such things, because human languages are very ambiguous and elliptic in nature. To make the docstring clear, you'd need at the very least to somehow mark "fit a frame" in some kind of special way, so people understand that this is a special term with a very narrow meaning, explained elsewhere. And even then it's not clear that by "fit a frame to the current buffer" you really mean "pretend there's no other window", especially since the resulting behavior is just really odd. > Why prohibit a user from using this in situations where it is useful? Because it's clearly not a finished feature. It's like a car without windshield and doors and with a trunk that doesn't close: sure it can come in handy sometimes, but to most people it's just a broken car. When the feature is completed we can reconsider it. >> We might also want to have a variant that only shrinks the frame. >> Such a variant probably wouldn't need any customization. > Only shrinks it to what size? fit-frame can grow or shrink, depending on the situation. I'm proposing to provide a restriction of it that only shrinks (i.e. use the current size as an upper bound on the desired final size). Stefan