From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: wanted: someone to integrate frame-resizing code Date: 30 May 2004 17:11:53 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085951592 12673 80.91.224.253 (30 May 2004 21:13:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 30 May 2004 21:13:12 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 30 23:13:05 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BUXc9-0000Ys-00 for ; Sun, 30 May 2004 23:13:05 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BUXc9-0004Ii-00 for ; Sun, 30 May 2004 23:13:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUXcI-0000I1-12 for emacs-devel@quimby.gnus.org; Sun, 30 May 2004 17:13:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BUXc6-0000Df-O3 for emacs-devel@gnu.org; Sun, 30 May 2004 17:13:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BUXc4-0000BW-CR for emacs-devel@gnu.org; Sun, 30 May 2004 17:13:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUXc4-0000B8-4U for emacs-devel@gnu.org; Sun, 30 May 2004 17:13:00 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BUXbq-0001QC-31 for emacs-devel@gnu.org; Sun, 30 May 2004 17:12:46 -0400 Original-Received: from [206.47.199.165] (helo=simmts7-srv.bellnexxia.net) by mx20.gnu.org with esmtp (Exim 4.34) id 1BUXb1-0004f1-N9 for emacs-devel@gnu.org; Sun, 30 May 2004 17:11:55 -0400 Original-Received: from empanada.local ([67.70.165.15]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040530211152.KAJP19086.simmts7-srv.bellnexxia.net@empanada.local>; Sun, 30 May 2004 17:11:52 -0400 Original-Received: by empanada.local (Postfix, from userid 502) id 95A801BDB2E; Sun, 30 May 2004 17:11:53 -0400 (EDT) Original-To: "Drew Adams" In-Reply-To: Original-Lines: 90 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24245 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24245 > Even using my simple implementation, I never encountered a problem as a > user: automatic resizing only takes place when the buffer is displayed (e.g. > display-buffer), so it's not done after you resize a frame manually. I regularly (tho not often) do C-x 5 f where is already in an open frame. This basically has the effect of raising that frame and it should not resize it (even tho it does get "displayed" in the sense that pop-to-buffer is called on it). [ I don't distinguish between pop-to-buffer and display-buffer here. ] >> Maybe you could allow resizing existing frames when they get deiconified, >> but even that sounds risky. > No, just the opposite. We do *not* want to resize a frame when it is > deiconified. A user should be able to manually size a frame, iconify it, do > some stuff, and deiconify it to exactly the same position and size. We want > to automatically resize a frame only when it is displayed. I meant "deiconified by pop-to-buffer", not manually of course. [ I don't like to use "displayed" since it doesn't mean anything precise. ] >> - resizing frames showing the content of a file is probably not a great idea. > Reason? None other than my gut feeling. > Automatic resizing is just as handy for file buffers. Of course it's true that it's not uncommon to open a file just to look at it, but if not, a short frame might just turn out inconvenient as soon as I start adding text to the file. > You never see wrapped-around or truncated text, and you save a lot of > manual fiddling, resizing frames (you can still fiddle, if you want). I never fiddle with the horizontal size of file buffers: if text gets wrapped around, I want to fix the text, not the frame. > If I'm editing a short, narrow buffer and I switch to a longer, wider > buffer, I want the frame to be the right size for the latter. All my file frames are vertically maximized (and 80 columns). [ And I virtually never switch buffers in a frame. ] > It doesn't matter whether or not a buffer is associated with a file. Could be. I just know that I currently manage the two very differently, mostly because I use the two kinds of buffers very differently: in file buffers, I edit, I move around, etc, whereas in non-file buffers I generally don't do much more than click on a few things. >> More generally, if the elisp code doesn't call >> shrink-window-if-larger-than-buffer, it's likely that the frame's size >> shouldn't be changed either. > Not sure I follow you. This has nothing to do with resizing windows. Why not? shrink-window-if-larger-than-buffer is basically the same as you code, if you consider that it's typically used for single-frame Emacs instances where Emacs manages all the windows whereas your code works for multi-frame Emacs instances where the window manager manages the windows (indirectly by managing the frames). > Automatic frame resizing is done only when the selected window is alone in > the frame (one-window-p). Whether code resizes windows or not is not > pertinent to what should happen when each window is in its own frame. > It's a different UI model. I don't find it very different: Emacs's windows don't overlap, but otherwise it's pretty similar. > Are there other circumstances where screen size can be "significantly > smaller" than the display? When I connect my 1280x1024 external monitor to my 1024x768 laptop, I get a virtual screen of 1304x1024 or 1280x1792 pixels (where some are non-displayed, some are displayed on the laptop's screen and the rest is on the external monitor). > I'm not aware of a better measure of display size in pixels than > x-display-pixel-height/width. Neither am I. The above email is not a comment about your code. It's just some comments based on my own use pattern. I don't claim it has any kind of representative quality. Stefan