From: Stephen Berman <stephen.berman@gmx.net>
To: emacs-pretest-bug@gnu.org
Subject: bug#3243: 23.0.93; display problem with default resize-mini-windows
Date: Sat, 09 May 2009 00:06:02 +0200 [thread overview]
Message-ID: <87iqkbi71x.fsf@escher.local.home> (raw)
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 is a regression with respect to Emacs 22. There, the *Completions*
buffer displays even just two file names in two columns, and regardless
of how high the mode line is, it does not obscure the last file name.
In GNU Emacs 23.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
of 2009-05-03 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
next reply other threads:[~2009-05-08 22:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-08 22:06 Stephen Berman [this message]
2014-12-25 10:35 ` bug#3243: 23.0.93; display problem with default resize-mini-windows martin rudalics
2015-01-02 16:20 ` Stephen Berman
2015-01-03 17:17 ` martin rudalics
2015-01-03 18:20 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87iqkbi71x.fsf@escher.local.home \
--to=stephen.berman@gmx.net \
--cc=3243@emacsbugs.donarmstrong.com \
--cc=emacs-pretest-bug@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).