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: Mon, 10 Mar 2008 09:04:59 -0800 Message-ID: <000f01c882d0$df847ef0$c2b22382@us.oracle.com> References: <004301c88269$637220e0$0600a8c0@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 1205169185 18916 80.91.229.12 (10 Mar 2008 17:13:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2008 17:13:05 +0000 (UTC) Cc: 'Emacs-Devel' To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 10 18:13:24 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 1JYlXX-0001AB-7v for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 18:11:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYlWy-00042i-Sz for ged-emacs-devel@m.gmane.org; Mon, 10 Mar 2008 13:11:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYlSZ-0001m4-7J for emacs-devel@gnu.org; Mon, 10 Mar 2008 13:06:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYlSU-0001jI-HR for emacs-devel@gnu.org; Mon, 10 Mar 2008 13:06:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYlSU-0001jC-DU for emacs-devel@gnu.org; Mon, 10 Mar 2008 13:06:42 -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 1JYlST-0007QW-Qa for emacs-devel@gnu.org; Mon, 10 Mar 2008 13:06:42 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m2AH6cmA006009; Mon, 10 Mar 2008 11:06:38 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m29IWneo008173; Mon, 10 Mar 2008 11:06:37 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3606663631205168705; Mon, 10 Mar 2008 10:05:05 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Mar 2008 10:05:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AciCxGY02eaU3ULrTQyHqMOxe6Qy9AAAoJXw 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:92061 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. The same fitting algorithm is applied to each buffer, to try to find what would be an ideal fit for it alone. The requisite widths and heights are summed to produce the overall ideal frame size to show all of the frame's buffers. Then the frame-size limits are applied. Obviously, frame fitting is most useful for either one-window frames or frames with some buffers that are narrow or short (depending on their positions). > I get the impression that part of the problem is that you > calculate a frame size that would allow all windows to have the right > size, but you don't actually resize the windows, so they get > a somewhat arbitrary size which may or may not be the right one. You can put it that way, if you like. It is by design that there is no explicit attempt to resize the windows, relative to each other, to achieve an overall "best window configuration", whatever that might mean (depends on what you want, in general and in any specific context). But the relative sizes of windows can change as a side effect, of course. It's not obvious, for instance, that you would want, say, a proportional reduction of each window from its ideal shrink-fit size, in order to fit all of them within the calculated frame size. You might instead want to privilege one window (display its buffer fully, if possible, or as much of it as possible). Or you might instead want to privilege some subset of the windows in different ways. You might have a set of buffers (e.g. with names matching some regexp) that you want to always receive more emphasis (privilege during resizing), and you might have another set that you want to receive less emphasis. You might also want buffer mode to be taken into account - for example, it make little sense to measure the width of a line in longlines mode. Because the possibilities of window sizes within a given frame are numerous and can depend on user preference, which buffers and modes are involved, and other things (phase of moon?), it would be an interesting discussion to come up with a good design that DTRT generally and lets users easily control relative window resizing. Designing different window resizing possibilities and how to specify interactively which of them you want at any time, perhaps in combination with frame resizing, is, in any case, a task for the future. 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. ;-) > 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). > 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. In many cases, you might not want that behavior. Don't use plain `C-u' when you don't want that behavior. > I'd have expected it to resize the frame so that the window fits the > buffer, and so that the other windows stay "unchanged". As I said, windows are not resized, except as a side effect of fitting the frame. Integrating possible window resizing with frame resizing can be a future challenge. It's not obvious what window-resizing behavior one might want in different contexts. When that possible combination (frame and window resizing) is considered, it might be useful to revisit the prefix-arg and user option possibilities. More or different options and prefix-arg values might need to be considered, to take into account mixing frame and window resizing. The main use case to think about here is one-window frames. The default behavior (no prefix arg) also does something for multi-window frames that can be useful in some contexts, but I expect that most people will use this as I do, to resize one-window frames. Another important use case is calling it from Lisp code. Note: There is a companion library, autofit-frame.el, that provides automatic frame-fitting for the one-window case (only). However, that library redefines display-buffer, switch-to-buffer, and pop-to-buffer. Richard suggested that that logic be incorporated into the C source code, after fit-frame.el has been added to Emacs. I won't be coding that C code myself, but I can provide the Lisp code to help with the logic. IMO, it is very handy to some users, such as I, who use frames the way most users use windows. Use of automatic frame fitting is optional, of course. HTH.