bug#3243: 23.0.93; display problem with default resize-mini-windows

[Stephen Berman <stephen.berman@gmx.net>]

On Thu, 25 Dec 2014 11:35:44 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> 1. emacs -Q
>> 2. M-x customize-face RET mode-line RET, then set the height attribute
>>    to a scale value of 1.3 (the problem described in step 4 may depend
>>    on the font used; if it does not appear with this scale value, it
>>    should with a larger one).
>> 3. For this step, you need to have at least two files in a directory,
>>    whose names are in a substring relation to each other, e.g. file1,
>>    file12.  Further, either the file names themselves or the path+file
>>    names must be long enough so that when inserted by completion after
>>    the dired prompt, the string is almost as long as the window is wide,
>>    but not so long as to induce line wrapping in the minibuffer.  Now
>>    type: `C-x d' and at the prompt enough of the file names (or
>>    path+file names) so that when you type TAB, you get the message
>>    "[Complete, but not unique]".
>> 4. Note that the latter message wraps, forcing the minibuffer to grow.
>>    After the message disappears, the minibuffer retains its increased
>>    height, due to the default setting of resize-mini-windows, grow-only.
>>    The display problem is in the *Completions* buffer: the file names
>>    are displayed in a single column (at least with only two or three
>>    files), and the last file name is slightly hidden by the enlarged
>>    mode line.  (If resize-mini-windows is set to t, the last file is at
>>    first hidden, but when the message disappears, the minibuffer shrinks
>>    again and the last file name is displayed completely.)
>
> This should work now but your scenario is a bit too contrived for me.
> Can you please try with latest trunk/master?
>
> Thanks, martin

Sorry for the late reply, I was away.  I just rebuilt from latest master
(emacs-repository-version "d0ca1148fe2d1e72e86f0197731071f139c143e3")
and cannot reproduce the problem I reported above.  In fact, I cannot
reproduce it with my previous build from 2014-12-09,
emacs-repository-version "baab20d73e2a3ee6a06dc83fe97d0b781870e29f".  In
any case, it appears the problem is fixed; thanks.

Steve Berman