* bug#3285: 23.0.91; Messaging propertized text increases minibuffer height unnecessarily
@ 2009-05-14 6:05 Brent Goodrick
0 siblings, 0 replies; 5+ messages in thread
From: Brent Goodrick @ 2009-05-14 6:05 UTC (permalink / raw
To: emacs-pretest-bug
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]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#3285: 23.0.91; Messaging propertized text increases minibuffer height unnecessarily
@ 2009-05-14 19:36 Chong Yidong
2009-05-15 3:47 ` Brent Goodrick
0 siblings, 1 reply; 5+ messages in thread
From: Chong Yidong @ 2009-05-14 19:36 UTC (permalink / raw
To: Brent Goodrick; +Cc: 3285
> 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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#3285: 23.0.91; Messaging propertized text increases minibuffer height unnecessarily
2009-05-14 19:36 Chong Yidong
@ 2009-05-15 3:47 ` Brent Goodrick
2009-05-15 13:57 ` Drew Adams
0 siblings, 1 reply; 5+ messages in thread
From: Brent Goodrick @ 2009-05-15 3:47 UTC (permalink / raw
To: Chong Yidong; +Cc: 3285
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#3285: 23.0.91; Messaging propertized text increases minibuffer height unnecessarily
2009-05-15 3:47 ` Brent Goodrick
@ 2009-05-15 13:57 ` Drew Adams
2009-05-21 15:05 ` Brent Goodrick
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2009-05-15 13:57 UTC (permalink / raw
To: 'Brent Goodrick', 3285, '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?
>
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#3285: 23.0.91; Messaging propertized text increases minibuffer height unnecessarily
2009-05-15 13:57 ` Drew Adams
@ 2009-05-21 15:05 ` Brent Goodrick
0 siblings, 0 replies; 5+ messages in thread
From: Brent Goodrick @ 2009-05-21 15:05 UTC (permalink / raw
To: Drew Adams; +Cc: 3285, Chong Yidong
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-21 15:05 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-14 6:05 bug#3285: 23.0.91; Messaging propertized text increases minibuffer height unnecessarily Brent Goodrick
-- strict thread matches above, loose matches on Subject: below --
2009-05-14 19:36 Chong Yidong
2009-05-15 3:47 ` Brent Goodrick
2009-05-15 13:57 ` Drew Adams
2009-05-21 15:05 ` Brent Goodrick
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.