bug#10409: Minibuffer sized according to default face, not minibuffer face

bug#10409: Minibuffer sized according to default face, not minibuffer face

[David Reitter]

X-Debbugs-CC: Jeremy Thurgood <firxen@gmail.com>


Jeremy,
can you please try this out with the latest nightly build (Emacs 24), available from http://aquamacs.org/nightlies.shtml
and update this bug with the version number (and ideally everything from Help->Diagnosis->Report Bug).
Please use Help->Diagnosis->Start without customizations.

Thanks
- David


Begin forwarded message:

> From: Jeremy Thurgood <firxen@gmail.com>
> Subject: [Aquamacs-bugs] Minibuffer sized according to default face, not minibuffer face
> Date: December 29, 2011 9:52:52 AM GMT+01:00
> To: aquamacs-bugs@aquamacs.org
> Reply-To: Bug reports for Aquamacs Emacs <aquamacs-bugs@aquamacs.org>
> 
> Good day,
> 
> I'm not sure if this is a bug or if it's just non-obvious behaviour,
> 
> The height of the minibuffer (in pixels) is set in increments of the
> line height for the default face. If the echo area face (the one from
> which all minibuffer faces inherit) is slightly taller than the
> default face, this means that the minibuffer is one line high when
> empty and two lines high if there's anything in it. As a consequence,
> the minibuffer is constantly resizing, which is visually jarring. In
> my case, I set my default face to a font that is a little shorter then
> Lucida Grande (the default font for the echo area face) and ran into
> this behaviour. It can be replicated merely by setting the echo area
> face's height to a large scale -- 1.5 will do.
> 
> As a workaround, the height of the minibuffer face can be adjusted to
> a scale less than 1.0 to make the line height fit. Alternatively, the
> font can be changed to one that fits better. In my case, I just
> removed the override and allowed it to inherit the font from my
> default face. It looks a bit uglier, but it lets me avoid tinkering
> with the height whenever I change the default font.
> 
> Thanks,
> --J

bug#10409: Minibuffer sized according to default face, not minibuffer face

[Jeremy Thurgood]

On Fri, Dec 30, 2011 at 10:19, David Reitter <david.reitter@gmail.com> wrote:
>
> can you please try this out with the latest nightly build (Emacs 24), available from http://aquamacs.org/nightlies.shtml

I see the same on the latest nightly, both with and without customizations:

In GNU Emacs 24.0.90.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2011-12-30 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns' '--without-x' 'CFLAGS=-arch
i386 -g -O0 ' 'LDFLAGS=-arch i386 -g -O0 ''

> and update this bug with the version number (and ideally everything from Help->Diagnosis->Report Bug).

Whoops, I knew I was forgetting something. Here are the relevant extracts:

In GNU Emacs 23.3.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2011-10-25 on braeburn.aquamacs.org - Aquamacs Distribution 2.4
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns' '--without-x' 'CC=gcc'
'CFLAGS=-O0 -g -arch i386' 'LDFLAGS=-O0 -g -arch i386''

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: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
mailabbrev nnheader gnus-util netrc gmm-utils mailheader canlock sha1
hex-util hashcash mail-utils emacsbug autorevert flymake flymake-cursor
twisted-dev python-21 python lilypond-mode compile comint run-tests
ansi-color git-emacs ido git-emacs-autoloads git-global-keys time-stamp
vc-git vc vc-dispatcher ediff psvn derived edmacro kmacro log-edit ring
pcvs-util add-log diff-mode pp elp ediff-merg ediff-diff ediff-wind
ediff-mult ediff-help ediff-init ediff-util dired uniquify erlang-start
zoom-replacement load-emacs-plugins aquamacs-mode-defaults auctex-config
server preview-latex tex-site auto-loads aquamacs-aux savehist mouse-sel
one-buffer-one-frame smart-frame-positioning drews_init
color-theme-autoloads saveplace visual-line aquamacs-bug
aquamacs-autoface-mode aquamacs-editing sendmail rfc2047 rfc2045
ietf-drums qp mm-util mail-prsvr recentf tree-widget cus-edit osxkeys
emulate-mac-keyboard-mode frame-cmds strings misc-fns thingatpt+
thingatpt frame-fns avoid aquamacs-mac-fontsets fit-frame
aquamacs-frame-setup aquamacs-tabbar tabbar-window cl cl-19 cus-start
cus-load tabbar easy-mmode warnings load-emacs-pre-plugins
aquamacs-site-start cocoa-compatibility matlab-load smart-dnd filladapt
aquamacs-redo check-for-updates aquamacs-menu osx_defaults
aquamacs-tool-bar aquamacs mac-extra-functions aquamacs-tools
aquamacs-macros parse-time timezone time-date paren delsel pc-select
cua-base wid-edit regexp-opt advice advice-preload byte-opt bytecomp
byte-compile debug help-fns help-mode view image-file disp-table tooltip
ediff-hook vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process ns multi-tty emacs)

> Please use Help->Diagnosis->Start without customizations.

I have done so. I see the same behaviour.

Thanks,
--J

> Begin forwarded message:
>
>> From: Jeremy Thurgood <firxen@gmail.com>
>> Subject: [Aquamacs-bugs] Minibuffer sized according to default face, not minibuffer face
>> Date: December 29, 2011 9:52:52 AM GMT+01:00
>> To: aquamacs-bugs@aquamacs.org
>> Reply-To: Bug reports for Aquamacs Emacs <aquamacs-bugs@aquamacs.org>
>>
>> Good day,
>>
>> I'm not sure if this is a bug or if it's just non-obvious behaviour,
>>
>> The height of the minibuffer (in pixels) is set in increments of the
>> line height for the default face. If the echo area face (the one from
>> which all minibuffer faces inherit) is slightly taller than the
>> default face, this means that the minibuffer is one line high when
>> empty and two lines high if there's anything in it. As a consequence,
>> the minibuffer is constantly resizing, which is visually jarring. In
>> my case, I set my default face to a font that is a little shorter then
>> Lucida Grande (the default font for the echo area face) and ran into
>> this behaviour. It can be replicated merely by setting the echo area
>> face's height to a large scale -- 1.5 will do.
>>
>> As a workaround, the height of the minibuffer face can be adjusted to
>> a scale less than 1.0 to make the line height fit. Alternatively, the
>> font can be changed to one that fits better. In my case, I just
>> removed the override and allowed it to inherit the font from my
>> default face. It looks a bit uglier, but it lets me avoid tinkering
>> with the height whenever I change the default font.
>>
>> Thanks,
>> --J
>
>
>

bug#10409: Minibuffer sized according to default face, not minibuffer face

[David Reitter]

With further info from Jeremy, it looks like it works as designed.  

So would like to use this bug to request an enhancement (to allow for arbitrary (pixel level) window heights, with minibuffers sized according to the minibuffer face rather than the default face).


Begin forwarded message:

> On Fri, Dec 30, 2011 at 10:16, David Reitter <david.reitter@gmail.com> wrote:
>> I'm afraid part of this is an artifact of Emacs' long-standing way of measuring the heights of frames and windows in full glyph (or line) heights of the default face, even on post-1984 systems that have graphical user interfaces.

From: Jeremy Thurgood <firxen@gmail.com>

> Two lines (of the default face's height) are needed to display one
> line of the echo area's face. In my original case, the default face at
> 13pt was 12 pixels high (I think) and the echo area face at 13pt was
> 13 pixels high, so the minibuffer grew a second line (at the default
> face's height) for a total of 24 pixels so it could display the 13
> pixel high text without cutting any off. If there's a larger disparity
> in size, the need for multiple default-height lines in the minibuffer
> is more apparent.

bug#10409: Minibuffer sized according to default face, not minibuffer face

[Chong Yidong]

>> The height of the minibuffer (in pixels) is set in increments of the
>> line height for the default face. If the echo area face (the one from
>> which all minibuffer faces inherit) is slightly taller than the
>> default face, this means that the minibuffer is one line high when
>> empty and two lines high if there's anything in it.

What is the "echo area face" you are referring to?

Please provide a precise step-by-step recipe for reproducing this bug,
starting from emacs -Q.

bug#10409: Minibuffer sized according to default face, not minibuffer face

[martin rudalics]

>>> The height of the minibuffer (in pixels) is set in increments of the
>>> line height for the default face. If the echo area face (the one from
>>> which all minibuffer faces inherit) is slightly taller than the
>>> default face, this means that the minibuffer is one line high when
>>> empty and two lines high if there's anything in it.
> 
> What is the "echo area face" you are referring to?
> 
> Please provide a precise step-by-step recipe for reproducing this bug,
> starting from emacs -Q.

This could be bug#6192.  Look for Stefan's summary late
in the thread (skipping all my postings, at least).

martin