From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: automatic frame-resizing Date: Mon, 31 May 2004 17:34:13 -0700 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" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1086050098 30176 80.91.224.253 (1 Jun 2004 00:34:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Jun 2004 00:34:58 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 01 02:34:50 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 1BUxEw-0001vc-00 for ; Tue, 01 Jun 2004 02:34:50 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BUxEv-00017W-00 for ; Tue, 01 Jun 2004 02:34:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUxF8-0001HW-FX for emacs-devel@quimby.gnus.org; Mon, 31 May 2004 20:35:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BUxF3-0001Ft-FI for emacs-devel@gnu.org; Mon, 31 May 2004 20:34:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BUxF1-0001DY-F0 for emacs-devel@gnu.org; Mon, 31 May 2004 20:34:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUxF1-0001DN-Ay for emacs-devel@gnu.org; Mon, 31 May 2004 20:34:55 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BUxEX-0001Fa-0C for emacs-devel@gnu.org; Mon, 31 May 2004 20:34:25 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by agminet01.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i510YKHU025468; Mon, 31 May 2004 17:34:21 -0700 Original-Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i510YJDG008767; Mon, 31 May 2004 18:34:20 -0600 Original-Received: from dradamslap (dhcp-amer-vpn-gw2-east-141-144-65-159.vpn.oracle.com [141.144.65.159]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i510YGDN008693; Mon, 31 May 2004 18:34:19 -0600 Original-To: "Stefan Monnier" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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:24328 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24328 > 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 Stefan, your point on not resizing existing frames when raising them by function is a valid one - I agree 100%. If automatic frame resizing is added to Emacs, then simply raising an existing frame (whether iconified, invisible, or already raised) should not by itself trigger resizing. Resizing should only happen when the buffer in the frame changes (different buffer or different contents for the same buffer). It is not necessary to adopt the sort of implementation of automatic frame resizing I used, but *if* an implementation is done along those lines (that is, if the resizing is done in display-buffer and switch-to-buffer), then it is necessary to modify the C code for display-buffer and switch-to-buffer: If an existing frame is simply being raised, then do not resize it. (Pop-to-buffer, switch-to-buffer-other-frame, and switch-to-buffer-other-window are taken care of by display-buffer; switch-to-buffer does not use display-buffer, so it needs to be modified separately.) I did not try to change any C code: my implementation is a simple Lisp hack/workaround. I just called the built-in functions from Lisp, doing a resize-frame afterward (if one-window-p). I don't know of any way in Lisp to determine whether an existing frame was in fact reused by display-buffer or switch-to-buffer. I do at least inhibit resizing in switch-to-buffer (same frame) in the case where the original buffer and the new buffer are the same. So, my code does in fact step on the user by resizing upon programmatic frame-raise and other pop-to-buffer calls like find-file. Given that I could not change the C code, I preferred this to giving up automatic resizing for things like find-file. For the rest of your remarks - I don't want to belabor this. I already mentioned that my implementation is a simple one, not ideal. I listed what I think are the requirements for a more exact solution. I argued for adding the functionality of automatic frame resizing, not my implementation of that. (I also argued that my command to resize a frame could be added more or less as is, independently of any automatic resizing.) It sounds like your file editing is a special case, though perhaps not uncommon: you apparently edit mainly files with the same (max) line width, so you just use an appropriate constant frame width. In general, though, there are lots of kinds of file, with different (max) line widths or fill-columns. I believe that it makes as much sense to shrink-wrap a file frame as a dired, help, info, or any other frame. (And you can always impose a constant frame width for your file editing, if you like.) Regarding your concern that a short file frame might be inconvenient for appending to: a user can establish a minimum frame height in several ways. You can use the same value you now use for your file frames, if you like. Thanks, Drew P.S. I simplified some of my code (and renamed shrink-* to resize-*); here it is: - http://www.emacswiki.org/elisp/auto-resize-frames.el - http://www.emacswiki.org/elisp/resize-frame.el