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: resize-mini-windows... Date: Wed, 14 Mar 2007 00:28:55 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1173857387 14160 80.91.229.12 (14 Mar 2007 07:29:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Mar 2007 07:29:47 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 14 08:29:38 2007 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 1HRNvV-0002jh-K1 for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2007 08:29:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRNwL-0007eV-Bt for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2007 02:30:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HRNwE-0007eN-KL for emacs-devel@gnu.org; Wed, 14 Mar 2007 03:30:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HRNwB-0007e6-7w for emacs-devel@gnu.org; Wed, 14 Mar 2007 03:30:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRNwA-0007e3-Oh for emacs-devel@gnu.org; Wed, 14 Mar 2007 02:30:19 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HRNvH-0003H3-M2 for emacs-devel@gnu.org; Wed, 14 Mar 2007 03:29:24 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2E7TE4u023309 for ; Wed, 14 Mar 2007 02:29:14 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2E70iJg030907 for ; Wed, 14 Mar 2007 01:29:13 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-65-26.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2527011461173857343; Wed, 14 Mar 2007 00:29:03 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: 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:67897 Archived-At: > > Please explain what its advantages are, how it is better than the > > alternatives, what the "annoying problems of the alternatives" > > are, and what the "fine compromise" amounts to. > > I'm not going to get drawn into another one of your drawn-out Asberger's > fests, Drew. I already explained the reasons. Leave the personal insults and projection behind, please. You said only that it has been discussed many times (where?) and it represents a fine compromise (= what?). I searched the archives, but I didn't find much on this. I found the thread that I introduced in January 2007 and a thread from 2003 about resizing of the echo area being too eager: "[Annoyance] resizing of echo area is too eager". I found no other pertinent mention of `resize-mini-windows' in `emacs-devel' or `emacs-pretest', by searching gmane. The "[Annoyance]" thread did indicate indirectly that `resize-mini-windows' affects not only minibuffer size but also echo-area size, as you also indicated by referring to output messages. This was news to me. I don't see that explained in the doc anywhere. It's not obvious, given the function name and a doc string that makes no mention of it, that this option also controls echo-area resizing, that is, both input and output. Also, as I said, I don't see this option mentioned in the Elisp manual. My Emacs snapshot dates from January 25, so perhaps the doc was improved after that date. Perhaps someone with a recent snapshot will check. I would expect to see this option discussed in the same node as `max-mini-window-height'. The "[Annoyance]" thread from 2003 pointed out that `grow-only' suffered from the same problem reported there, that is, it is *not* a "fine compromise", at least for the annoyance reported in that thread. That thread mentions what I think is the same bug that I reported in January: if 2 pixels more height are added by :boxing a character, the minibuffer is resized (grown), but with a nil value the box is shown completely (so no resizing should really be necessary here). In that "[Annoyance]" thread, instead of a boxed character, it was a Korean character with an ascent one point higher. This was the too-eager annoyance reported. And `grow-only' did nothing to help it - only nil worked. The explanation given for the bug was what I thought: resizing uses an integral number of character lines. So, the annoyance will be there until we either find a way to do fine-grained resizing or we allow a threshold (fudge factor) before resizing. Using a reasonable threshold, vertical addition of a mere pixel or two by :boxing, or addition of a mere point from an ascent or descent, would not grow the window. As I said, the box shows completely without resizing, but apparently the code insists that there be a certain amount of blank space above and below. The fudge factor should take that into account. (It could even be a user option, perhaps useful especially for certain languages.) I found no other discussion of `resize-mini-windows', so I don't know what you're referring to - where was it "discussed many times"? I propose that, as is currently (January, at least) stated (erroneously) in the Elisp manual, t be the default value, not `grow-only'. Arguments against? Is there no way to get the pre-Emacs 22 behavior for the minibuffer, where long input lines wrap, but there is otherwise no resizing? Setting the value to nil stops vertical resizing (it is the only way to do that), but it also truncates long input or a long message. Can we separate inhibition of vertical resizing from truncation?