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

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

[Brent Goodrick]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

This defect is reported against Emacs built from CVS top of trunk source
within the last month, but this issue may have existed before then. 

Description of the defect:

Run this command from the command-line on that version of Emacs:

emacs -q --eval="(progn (message \"%s\" (let ((doc \"(SEXP)\"))
						(add-text-properties 1 5 (list 'face '((t (:inherit italic)))) doc)
						doc))
                        (message \"minibuffer height was %d\" (window-height (minibuffer-window))))"

Notice that the message shows height was 1.

Do that command again, but change it to bold:

emacs -q --eval="(progn (message \"%s\" (let ((doc \"(SEXP)\"))
						(add-text-properties 1 5 (list 'face '((t (:inherit bold)))) doc)
						doc))
                        (message \"minibuffer height was %d\" (window-height (minibuffer-window))))"

Notice that the height changes to 2 lines.

The maximum height of the regular sized font versus of the bold font
can NOT be so different as to cause the minibuffer have to increase in
height from 1 line to 2 lines.

The reason this is a big deal is because of eldoc mode. Enabling it
and moving the point over the first or any subsequent argument of an
Emacs Lisp function causes eldoc mode to call `message' with
propertized text that highlights the expected argument by changing the
font of that argument to be in bold font face in the text that is
displayed. But it seems that the bold font face then causes the
minibuffer to resize vertically to 2 lines instead of only 1 line. If
you are editing code in that window that is just above the minibuffer,
then the point in that window (relative to the main window) keeps
shifting around on the screen each time the cursor moves from typing
the function name to the first argument. And it gets worse when moving
around in the buffer which is visiting Elisp code, since it is likely
that the cursor crosses over functions or arguments of those functions
thus causing the minibuffer to keep changing height.

FYI, `eldoc-highlight-function-argument' is the function in
share/emacs/23.0.91/lisp/emacs-lisp/eldoc.el.gz that propertizes the
text, but the problem, in my opinion, is not with eldoc mode, but in
how emacs decides to resize the minibuffer based upon certain faces
such as the bold face.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/home/brentg/install/Linux.i686/share/emacs/23.0.91/etc/DEBUG for instructions.


In GNU Emacs 23.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.12.11)
 of 2009-02-28 on yoga
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--with-x-toolkit' '--with-xft' '--prefix=/home/brentg/install/Linux.i686''

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: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Shell

Minor modes in effect:
  desktop-save-mode: t
  erc-ring-mode: t
  erc-services-mode: t
  erc-networks-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  iswitchb-mode: t
  delete-selection-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: 1
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
C-SPC C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-r 
w i n d o w - e i <backspace> <backspace> h e i g h 
t C-l C-M-u C-f C-w C-s C-/ C-s C-w C-s M-b <help-echo> 
<help-echo> C-x o C-x o C-M-u C-M-SPC C-z C-x o C-v 
C-M-p m e s s a g e SPC M-" m i n i b u f e r <backspace> 
<backspace> f e r SPC h i e <backspace> <backspace> 
e i g h t SPC i s SPC % d C-f SPC C-e C-p C-p C-p M-b 
M-b M-b M-b M-b M-f M-f M-b C-M-u C-M-SPC C-w C-v C-a 
<tab> C-e <return> <help-echo> M-P C-l C-a C-M-SPC 
C-w C-p C-f C-M-u C-M-u C-M-n C-q C-j C-v C-n C-p C-a 
C-f C-f C-f C-f C-f C-f C-f C-f C-f \ C-f C-f C-f C-f 
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f 
C-f C-f C-f C-f C-f C-f C-f \ > <backspace> <backspace> 
\ M-> <return> M-P M-b M-b M-b M-b M-b M-b M-f M-f 
M-f M-b C-M-SPC w a s M-> <return> M-P C-p C-p C-p 
C-e C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b 
C-b C-M-SPC i t a l i c M-> <return> M-x e m a c <tab> 
b <tab> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> s c <backspace> <backspace> c s - r e <tab> 
<C-backspace> r e p o r t <tab> <tab> <tab> <tab> <tab> 
<tab> e <tab> <tab> b <tab> <return>

Recent messages:
Pushed a window configuration. [2 times]
Mark saved where search started
Mark set [4 times]
History item: 1
Mark set [3 times]
History item: 1
Mark set [2 times]
History item: 1
Mark set [2 times]
Making completion list... [2 times]

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

[Chong Yidong]

> Notice that the height changes to 2 lines.
>
> The maximum height of the regular sized font versus of the bold font
> can NOT be so different as to cause the minibuffer have to increase in
> height from 1 line to 2 lines.

I'm afraid I don't observe this.  Use a bold font does not resize the
minibuffer.  What font are you using?

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

[Brent Goodrick]

On Thu, May 14, 2009 at 12:36 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>
> > Notice that the height changes to 2 lines.
> >
> > The maximum height of the regular sized font versus of the bold font
> > can NOT be so different as to cause the minibuffer have to increase in
> > height from 1 line to 2 lines.
>
> I'm afraid I don't observe this.  Use a bold font does not resize the
> minibuffer.  What font are you using?

I'm using xft with the "Bitstream Vera Sans Mono-9" font.

Brent

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

[Drew Adams]

> > > Notice that the height changes to 2 lines.
> > >
> > > The maximum height of the regular sized font versus of 
> > > the bold font can NOT be so different as to cause the
> > > minibuffer have to increase in height from 1 line to 2 lines.
> >
> > I'm afraid I don't observe this.  Use a bold font does not 
> > resize the minibuffer.  What font are you using?
> 
> 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.

HTH.

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

[Brent Goodrick]

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