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: resize-mini-windows Date: Mon, 8 Jan 2007 15:24:21 -0800 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1168298729 24029 80.91.229.12 (8 Jan 2007 23:25:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2007 23:25:29 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 09 00:25:28 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 1H43rr-0003ub-8d for ged-emacs-devel@m.gmane.org; Tue, 09 Jan 2007 00:25:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H43rq-0003NJ-Ik for ged-emacs-devel@m.gmane.org; Mon, 08 Jan 2007 18:25:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H43rg-0003Mx-Bh for emacs-devel@gnu.org; Mon, 08 Jan 2007 18:25:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H43rf-0003Mi-Oj for emacs-devel@gnu.org; Mon, 08 Jan 2007 18:25:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H43rf-0003Mf-M5 for emacs-devel@gnu.org; Mon, 08 Jan 2007 18:25:15 -0500 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1H43rf-0004YA-8A for emacs-devel@gnu.org; Mon, 08 Jan 2007 18:25:15 -0500 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l08NPCVg005308 for ; Mon, 8 Jan 2007 16:25:12 -0700 Original-Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l08MoXCF027951 for ; Mon, 8 Jan 2007 16:25:11 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by rcsmt250.oracle.com with ESMTP id 2345961721168298663; Mon, 08 Jan 2007 16:24:23 -0700 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= 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:65016 Archived-At: 1. Shouldn't user option `resize-mini-windows' be documented in Elisp manual node Intro to Minibuffers, where the resizing is explained? That is, shouldn't we tell users that (and how) they can control the resizing? 2. With `resize-mini-windows' = `grow-only' (the default), if I put a face on a character in the minibuffer prompt, and the face has a :box with 1-pixel border, then the minibuffer grows about a character in height. That seems unnecessary - why should 2 more pixels in height necessitate such a gross resizing? I guess the answer is that frames and windows must be an integral number of characters in height. But it still seems odd. If I set `resize-mini-windows' = nil, the boxed character is shown completely, including both top and bottom box borders, so I don't think the resizing is because "the contents require more space" (from the doc). Something seems wrong with the computation of the needed height. Unless, that is, an additional space is supposed to always be present above and below the displayed characters. The Elisp manual also says, to introduce the idea of resizing, "The minibuffer's window is normally a single line..." It should say "The minibuffer's height is that of a single line", because as it stands now it gives the impression that additional lines are added during resizing. In what I see, there is still only a single minibuffer line (single line of text), but the minibuffer height is increased. FYI, this is the face I put on a character, to provoke the jump in height: (defface foo '((((type x w32 mac graphic) (class color)) (:box (:line-width 1 :color "Red") :foreground "Red" :background "Cyan")) (t (:inverse-video t))) "..." :group 'faces) If I use a standalone minibuffer frame, I see no change in height, BTW. Perhaps that is because there is sufficient height already; I'm not sure.