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: RE: wanted: someone to integrate frame-resizing code Date: Fri, 28 May 2004 18:21:46 -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 1085807642 31102 80.91.224.253 (29 May 2004 05:14:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 May 2004 05:14:02 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 29 07:13:55 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 1BTwAN-0008PU-00 for ; Sat, 29 May 2004 07:13:55 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BTwAN-0003a2-00 for ; Sat, 29 May 2004 07:13:55 +0200 Original-Received: from [127.0.0.1] (helo=mailman.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BTwAR-0003Ld-7A for emacs-devel@quimby.gnus.org; Sat, 29 May 2004 01:13:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BTwA1-0003Bu-Ab for emacs-devel@gnu.org; Sat, 29 May 2004 01:13:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BTwA0-0003BJ-4j for emacs-devel@gnu.org; Sat, 29 May 2004 01:13:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BTwA0-0003BD-22 for emacs-devel@gnu.org; Sat, 29 May 2004 01:13:32 -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 1BTw3K-0001Me-Pe for emacs-devel@gnu.org; Sat, 29 May 2004 01:06:43 -0400 Original-Received: from [148.87.2.201] (helo=inet-mail1.oracle.com) by mx20.gnu.org with esmtp (Exim 4.34) id 1BTsgC-0007F3-Gj for emacs-devel@gnu.org; Fri, 28 May 2004 21:30:32 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4T1NA4l022659; Fri, 28 May 2004 18:23:13 -0700 (PDT) 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 i4T1LsSG000998; Fri, 28 May 2004 19:21:54 -0600 Original-Received: from dradamslap (dhcp-amer-vpn-gw2-east-141-144-83-64.vpn.oracle.com [141.144.83.64]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i4T1LoYL000948; Fri, 28 May 2004 19:21:54 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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:24131 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24131 Stefan wrote: > - if special-display-buffer-names or special-display-regexp specifies > specific sizes, it should still be obeyed. Absolutely. There are several ways this can be done, depending on how the automatic resizing is implemented. If the built-in display functions (display-buffer etc.) do the automatic resizing (my implementation), users can just make sure their special-display-function (or the function in the special-display-buffer-names arg) inhibits resizing (a la inhibit-read-only) when calling display-buffer or whatever. Or, if we provide separate no-resize versions of the display functions (a la find-file-noselect), users can just make sure to call one of those. BTW, the same consideration holds for any other code that resizes a frame to a specific size. There is nothing special here about "special". :) > - resizing existing frames is risky: you want to make sure you don't undo > what the user did manually. So I'd refrain from doing it except for > frames where the user specifically asked for it. Yes, we must not undo what the user did. No, resizing existing frames is not "risky" - we just need to do it only when appropriate, and not step on the user. 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. Again, there were a couple corner cases where I had to ensure there was no resizing upon display: compile and occur are the only ones I encountered, but there may be others. (I did this just by locally binding an inhibit variable around the call to display-buffer.) A sophisticated implementation that corresponds exactly to the requirements I listed previously might be ideal. But even my simple solution is preferable (IMO) to restricting users to on-demand resizing. I've used automatic resizing for years, and never had it conflict with manual resizing. And of course, users can turn automatic resizing off. And it doesn't affect frames with more than one window (resize-frame, as a command, can be used in multi-window frames: the selected-window is determinant). > 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. > - resizing frames showing the content of a file is probably not a great idea. Reason? Automatic resizing is just as handy for file buffers. 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). 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. It doesn't matter whether or not a buffer is associated with a file. Try it. Ce n'est pas le fil a couper le beurre, mais c'est utile. BTW, since there is some discussion about word-wrapping lately - We could choose to make the resizing-inhibit variable buffer-local and inhibit resizing in long-line, word-wrapping modes. > 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. 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. > - don't enlarge the frame to be larger than the user's screen (which might > be significantly smaller than what x-display-pixel-height claims). The doc string of command shrink-frame-to-fit (resize-frame) explains the algorithm. There is a (user-definable) maximum frame height and width. By default, these limits are calculated relative to the display size and the frame's character size (based on user-definable max percentages). They can also be specified absolutely. There is also a (user-definable) minimum frame height and width for new non-empty frames. There is also a (user-definable) minimum frame height and width for new empty frames. In fact, there are two: one for normal empty frames and one for special empty frames (default, if no special-frame-function). The only problem I've had with using x-display-pixel-height/width is when I run Emacs on a different machine than my display - for instance, if I run Emacs on a workstation (with a large display), and access it from a laptop (with a small display). In that case, I just impose an absolute max size, based on my target display size. I know of no way for Emacs to figure out what the remote display I'm using is like. If there is a way, we should use it. Are there other circumstances where screen size can be "significantly smaller" than the display? I'm not aware of a better measure of display size in pixels than x-display-pixel-height/width. If there is one, that should be used instead. BTW - I mentioned too, in an earlier mail, that I have not tried this code with images or a mixture of font sizes. Perhaps some adjustment will be necessary to accomodate these. The current resizing code uses set-frame-size. It counts lines and measures maximum line-width (in characters) to determine the needed frame height (lines) and width (cols). - Drew