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: Tue, 13 Mar 2007 19:44:36 -0700 Message-ID: References: <87k5xkhp15.fsf@catnip.gol.com> 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 1173840366 8035 80.91.229.12 (14 Mar 2007 02:46:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Mar 2007 02:46:06 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 14 03:46:00 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 1HRJV1-0000Y8-B7 for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2007 03:45:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRJVq-0002tu-VT for ged-emacs-devel@m.gmane.org; Tue, 13 Mar 2007 21:46:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HRJVn-0002td-11 for emacs-devel@gnu.org; Tue, 13 Mar 2007 22:46:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HRJVk-0002tQ-Gs for emacs-devel@gnu.org; Tue, 13 Mar 2007 22:46:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRJVk-0002tN-BE for emacs-devel@gnu.org; Tue, 13 Mar 2007 21:46:44 -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 1HRJUt-0000oa-Qn for emacs-devel@gnu.org; Tue, 13 Mar 2007 22:45:52 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2E2jlwX025916 for ; Tue, 13 Mar 2007 21:45:47 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2E2jkUY004148 for ; Tue, 13 Mar 2007 20:45:46 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-65-26.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2526024011173840283; Tue, 13 Mar 2007 19:44:43 -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: <87k5xkhp15.fsf@catnip.gol.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:67882 Archived-At: > > Why is the default value for `resize-mini-windows' `grow-only'? > > I think that is annoying. I don't know what the advantage of > > `grow-only' is supposed to be, but I don't think it is a good > > choice for the default value. > > It's a fine compromise choice which offers the most important features, > and avoids the most annoying problems of the alternatives. 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. > This has been discussed many times, the default of `grow-only' is not > some random choice. I don't find any record of that discussion (or those "many" discussions). Can you please point me to it? > > What's wrong with t? > > There are fairly common situations where the resultant constant bouncing > around of the window layout will drive you insane. Think of times when > many messages are output quickly, e.g when byte-compiling a directory: > it's not unusual that half the messages are slightly longer than the > display width... Messages go in the echo area, not the minibuffer. What do they have to do with the question? > > or nil? > > Do you really think that's a good value? Where every single message > (and minibuffer edit!) over one line gets truncated? I didn't realize that nil truncates. Why is that? Who would ever want that behavior? I figured that nil would give you the line-wrapping behavior of pre-Emacs 22. Is there no value of the option to give you that behavior? What was wrong with that? It would make a fine default behavior (although I think the t behavior is even better). Please see the other points in my post, as well, including the two bugs (1 doc) I reported.