unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Re: Avoiding raising minibuffer?
       [not found]     ` <jwvhben9ew8.fsf-monnier+gnu.emacs.help@gnu.org>
@ 2010-12-10 19:12       ` Elena
  2010-12-11 16:24         ` Stephen Berman
  0 siblings, 1 reply; 2+ messages in thread
From: Elena @ 2010-12-10 19:12 UTC (permalink / raw)
  To: help-gnu-emacs

On Dec 9, 3:55 pm, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> >> Maybe the problem is that all windows can only take sizes that are
> >> multiples of the base text size, so it may look like "2 lines, one of
> >> them empty" while in reality it's just a single line that's slightly
> >> taller than the base text line (because of some face that changes the
> >> font used for that text) so Emacs has to add a whole extra line which
> >> will be mostly (but not completely) empty.
> > Right!  It was a bold face which caused the minibuffer to grow (e.g.:
> > Eldoc bold-ifing current function argument).  Before reading your
> > explanation I couldn't notice it.
>
> You might want to report it as a (minor) bug: bold should not make the
> text higher, IMHO,
>
>         Stefan

Oh, it's not a bug.  I'm using a bitmap font which lacks a bold
version, thus it is "boldified" by the system, resulting in a larger
font.  I've checked with another font.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Avoiding raising minibuffer?
  2010-12-10 19:12       ` Avoiding raising minibuffer? Elena
@ 2010-12-11 16:24         ` Stephen Berman
  0 siblings, 0 replies; 2+ messages in thread
From: Stephen Berman @ 2010-12-11 16:24 UTC (permalink / raw)
  To: help-gnu-emacs

On Dec 9, 3:55 pm, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> >> Maybe the problem is that all windows can only take sizes that are
> >> multiples of the base text size, so it may look like "2 lines, one of
> >> them empty" while in reality it's just a single line that's slightly
> >> taller than the base text line (because of some face that changes the
> >> font used for that text) so Emacs has to add a whole extra line which
> >> will be mostly (but not completely) empty.
> > Right!  It was a bold face which caused the minibuffer to grow (e.g.:
> > Eldoc bold-ifing current function argument).  Before reading your
> > explanation I couldn't notice it.
>
> You might want to report it as a (minor) bug: bold should not make the
> text higher, IMHO,

This problem is already in the bugtracker, bug#6192, which remains open.
Admittedly, that report is titled "eldoc-mode: unexpected recentering",
and the bold face problem only came out in the course of the discussion
(cf. your summary at
http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00368.html),
so it is probably indeed worth filing a separate report about it.

Steve Berman




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-12-11 16:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <245cee63-b99e-49e5-8867-31e9a5024d86@upsg2000gro.googlegroups.com>
     [not found] ` <jwvzkshhash.fsf-monnier+gnu.emacs.help@gnu.org>
     [not found]   ` <90ba205e-e534-480a-bbab-9dad3c604e3e@v23g2000vbi.googlegroups.com>
     [not found]     ` <jwvhben9ew8.fsf-monnier+gnu.emacs.help@gnu.org>
2010-12-10 19:12       ` Avoiding raising minibuffer? Elena
2010-12-11 16:24         ` Stephen Berman

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).