From xemacs-m  Fri Mar 21 18:50:23 1997
Received: from alphatech.com (erebus.alphatech.com [198.112.236.2])
	by xemacs.org (8.8.5/8.8.5) with SMTP id SAA26035
	for <xemacs-beta@xemacs.org>; Fri, 21 Mar 1997 18:50:22 -0600 (CST)
Received: from venus.alphatech.com by alphatech.com (4.1/SMI-4.1)
	id AA18280; Fri, 21 Mar 97 19:45:38 EST
Received: from pochacco.alphatech.com by venus.alphatech.com (4.1/SMI-4.1)
	id AA26494; Fri, 21 Mar 97 19:53:48 EST
Received: by pochacco.alphatech.com (SMI-8.6/SMI-SVR4)
	id TAA01699; Fri, 21 Mar 1997 19:43:14 -0500
Sender: greg@pochacco.alphatech.com
From: greg@alphatech.com (Greg Klanderman)
To: Stephan Herrmann <sh@prosun.first.gmd.de>
Cc: xemacs-beta@xemacs.org
Subject: Re: scrolling minibuffer? subwindow?
References: <rt209eh9og.fsf@first.gmd.de>
Reply-To: greg@alphatech.com
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
Date: 21 Mar 1997 19:43:11 -0500
In-Reply-To: Stephan Herrmann's message of 17 Mar 1997 15:31:27 +0100
Message-Id: <ugend84uzk.fsf@pochacco.alphatech.com>
Lines: 43
X-Mailer: Gnus v5.4.11/XEmacs 19.15



>>>>> "Stephan" == Stephan Herrmann <sh@prosun.first.gmd.de> writes:
Stephan> 
Stephan> Am I the only one who has trouble with long questions in the minibuffer?
Stephan> Try this
Stephan> (find-file "/some/long/non/existing/path/with/a/file/that/does/not/exists")
Stephan> 
Stephan> and tell me, what the questions is and how to answer it.
Stephan> The *only* way to solve this is, as far as I can see, to stretch the 
Stephan> Frame to a width of, say, 130 chars, which is not my preferred layout :-(

Yes, this is a real problem.  In many similar cases, using
rsz-minibuf.el helps (Steven suggested this when I had the same
question a couple months ago).  Try this in your .emacs

(resize-minibuffer-mode)
(setq resize-minibuffer-window-exactly nil)
(setq resize-minibuffer-window-max-height 10)

Unfortunately in the case you ask about, this doesn't work.

Since when I tried your example, I didn't actually see the end of the
prompt, I quickly assumed that it was using y-or-n-p.  When I started
using rsz-minibuf I looked at the code a bit and determined that for
commands like y-or-n-p that use (next-command-event) directly to read
the response, rsz-minibuf does not work.  So I hacked up a version of
y-or-n-p that uses read-from-minibuffer but it still didn't work.  :-(

Now, several hours later, I understand what's actually going on and
why Steven suggested resize-minibuffer-window-exactly=nil.  Basically,
the code that determines if the minibuffer needs to be resized is
broken - only the string being entered is considered, not the prompt.

The function resize-minibuffer-count-window-lines needs to somehow
take into account the prompt string.  I'm not sure how to do this, but
if anyone has suggestions I'm open to them.  Is there a way to ask how
many lines a string will take if displayed in a buffer?

If it can be done, I do have a new y-or-n-p that will then resize
appropriately, and resize-minibuffer-window-exactly could be set to t...

Greg

