From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: FW: fit-frame.el Date: Tue, 11 Mar 2008 10:45:03 -0800 Message-ID: <000001c883a8$05f16670$0600a8c0@us.oracle.com> 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" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205261162 22483 80.91.229.12 (11 Mar 2008 18:46:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Mar 2008 18:46:02 +0000 (UTC) Cc: 'Emacs-Devel' To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 11 19:46:20 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 1JZ9Tz-0000MT-F6 for ged-emacs-devel@m.gmane.org; Tue, 11 Mar 2008 19:45:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZ9TR-0005Ge-5e for ged-emacs-devel@m.gmane.org; Tue, 11 Mar 2008 14:45:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZ9TN-0005G6-7T for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:45:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZ9TK-0005Fe-F3 for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:45:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZ9TK-0005FZ-AH for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:45:10 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JZ9TJ-0001H7-RV for emacs-devel@gnu.org; Tue, 11 Mar 2008 14:45:10 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m2BIj7bP004732; Tue, 11 Mar 2008 12:45:07 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m2B8qo71000542; Tue, 11 Mar 2008 12:45:06 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3608133081205261106; Tue, 11 Mar 2008 11:45:06 -0700 Original-Received: from dradamslap1 (/141.144.106.216) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Mar 2008 11:45:05 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciDpGVzWcjm4D45S22aNru0D+Ba9gACN6NQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:92176 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. You can put "Fitting" in quotes, in "_Fitting a non-empty buffer means_", if you think that helps (I don't). If not, propose an improvement to the doc string. I spent several iterations over the doc string with Richard already. If you have a concrete suggestion, feel free to send it along. > > 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. I don't see anything that's unfinished. It works fine with one-window frames. It works fine with more than one window also, if you want to resize the frame so that a particular buffer (window) is displayed without wrapping. That is the feature, and it does that fine. You seem to be wanting something that it doesn't pretend to do. And something that you can't even describe (!): balance window sizes in some undefined ideal fashion. That's a different feature altogether. > When the feature is completed we can reconsider it. OK, forget about 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). I understood. The question is: shrinks to what size? It's easy enough to have a variant that does the same thing as now, but prohibits any expansion, if that's all you mean. I don't see why that's particularly useful, but it's easy enough to implement. And you can add a variant that only grows, instead of only shrinks. And a variant that only shrinks or only grows vertically, or horizontally... But it sounds like you're not interested, in general, so there's no sense bothering with any of that.