bug#3285: 23.0.91; Messaging propertized text increases minibuffer height unnecessarily

[Brent Goodrick <bgoodr@gmail.com>]

On Fri, May 15, 2009 at 6:57 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> I'm using xft with the "Bitstream Vera Sans Mono-9" font.
>
> I suspect this is the known problem, reported long ago, that if a face makes a
> character slightly taller, then an extra line is allocated to handle the extra 1
> or 2 pixels in height.
>
> I see this too, because I use a face with `box' for one character sometimes in
> the minibuffer (before the prompt), and that causes the minibuffer height to
> increase by a whole character height. The box outline is only 1 pixel thick, but
> those 2 pixels (box top + bottom) are enough to cause the faced character to be
> larger than the one character height allocated.
>
> Maybe (dunno) the same thing happens for bold - maybe the bold characters are a
> pixel or two taller.
>
> This was discussed in Emacs Devel long ago, but never fixed. Maybe there is no
> easy fix, as long as the minibuffer must be an integral number of chars high.
> Dunno.
>
> Yes, it is annoying. We accommodate ascenders and descenders (e.g. in p and d)
> as part of the character height, but we don't account for box outlines or
> (apparently?) for the thickness of bolding.

(I thought I had sent this reply, but found later that it had gotten
stuck in the "Draft bit bucket" 8) ).

I would be more than happy to just have the minibuffer clipped to one
line, with some part of the font clipped.  If not, I'll have to set
the defvar for that font being used in eldoc mode to use something
like inverse highlight using the same font to insure that the
minibuffer stays the same height.

I initially toyed with the idea of forcing the minibuffer to always be
one line tall, but that would undoubtedly interact badly with the
ever-so-useful incremental completion mode(s) where large lists of
things need to be shown in the minibuffer temporarily.

bg