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: Mon, 10 Mar 2008 14:24:27 -0400 Message-ID: References: <004301c88269$637220e0$0600a8c0@us.oracle.com> <000f01c882d0$df847ef0$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 1205173522 3323 80.91.229.12 (10 Mar 2008 18:25:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2008 18:25:22 +0000 (UTC) Cc: 'Emacs-Devel' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 10 19:25:50 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 1JYmgV-0005VF-Io for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 19:25:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYmfx-00022t-3U for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 14:24:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYmfs-00022e-NR for emacs-devel@gnu.org; Mon, 10 Mar 2008 14:24:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYmfr-00022P-8b for emacs-devel@gnu.org; Mon, 10 Mar 2008 14:24:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYmfr-00022M-1k for emacs-devel@gnu.org; Mon, 10 Mar 2008 14:24:35 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JYmfq-0002ro-Ul for emacs-devel@gnu.org; Mon, 10 Mar 2008 14:24:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQHADoa1UfO+JwVQWdsb2JhbACQdgEBAR4IEplRgQc X-IronPort-AV: E=Sophos;i="4.25,475,1199682000"; d="scan'208";a="15801592" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 10 Mar 2008 14:24:34 -0400 Original-Received: from pastel.home ([206.248.156.21]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id QVI22533; Mon, 10 Mar 2008 14:24:33 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C1155805A; Mon, 10 Mar 2008 14:24:27 -0400 (EDT) In-Reply-To: <000f01c882d0$df847ef0$c2b22382@us.oracle.com> (Drew Adams's message of "Mon, 10 Mar 2008 09:04:59 -0800") 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:92080 Archived-At: >> Could you describe what is the behavior of your function when >> there are more than 1 windows in the frame? After trying it out, >> I'm still not sure. > With no prefix arg, the frame is fit to all of the buffers displayed in it. > This means that, within the maximum frame-size limits (see the doc for these > - user variables), each buffer contributes to the frame size needed. There > is no explicit resizing of windows within the frame. If each buffer can be > shown fully (no display wrapping) with the frame still within its limits, > then each buffer will be shown fully. To me, as a user of your code, I found this behavior to look like your code is just buggy: after calling fit-frame on a frame with several windows, the result was a frame of different size, where some of the windows were too small for their buffers and others were too large, so it looked like it was just all messed up. > There is this TODO item in fit-frame.el: > ;; Emacs needs a command similar to `fit-frame' > ;; for windows, that is, a command that will fit > ;; the existing windows of a frame to their > ;; buffers, as well as possible. That could be > ;; then be used in combination with `fit-frame'. > Until that is available, I think that `fit-frame' does the best that can be > expected. The best use case for it is one-window-p frames, but it can also > be useful for other frames, depending on what they are showing. When you are > in a context where it is not useful, don't use it. ;-) I'm not convinced that this "best we can do" is useful. >> Also when the C-u arg is provided, it seems to resize the frame to the >> size it should have if it displayed only 1 window, > Correct (for plain C-u). That's what I inferred from the behavior, not from the docstring. >> whereas of course it's not the case: there are other windows >> there (otherwise C-u makes no difference anyway). So again, >> the result is somewhat unexpected. > It's not unexpected if that's what's described in the doc. The doc says: To fit the frame to all of its displayed buffers, use no prefix arg. To fit it to just the current buffer, use a plain prefix arg (`C-u'). 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). > The main use case to think about here is one-window frames. I think it makes sense to restrict its use to one-window-p (and hence throw away the C-u argument). And then rename it to fit-frame-to-buffer. We might also want to have a variant that only shrinks the frame. Such a variant probably wouldn't need any customization. Stefan