bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sun, 16 May 2010 20:50:58 +0200 martin rudalics <rudalics@gmx.at> wrote:

> Anyway.  With a trunk built on April 19th of this year I cannot
> reproduce any echo area resizing neither (a) with (add-hook ...) in my
> .emacs, (b) with (add-hook ...) evaluated in Emacs -Q before opening an
> .el file, and (c) with (turn-on-eldoc-mode) evaluated after opening an
> .el file.  As with Eli here the echo area doesn't resize any more.

This is on Windows, right?  Since I recollected that you run Emacs on
Windows, it surprised me when you reported seeing the resizing, although
Eli had reported not seeing it on Windows.  So I guess it's good that
there is no discrepancy between you after all.  As I suggested to Eli,
maybe it's a GTK+ issue (but see below).

>> No, the Eldoc message is shown with faces and the echo area is resized
>> (because the argument face is bold).  Eldoc mode sets the faces via
>> propertize, which evidently is not affected by font-locking.
>
> There's an `add-text-properties' in `eldoc-highlight-function-argument'.
>
> BTW did you check how customizing `eldoc-echo-area-use-multiline-p' fits
> into this?

That makes no difference: with each of the three possible values, I get
the resizing.

However, it occurred to me that the font could make a difference -- and
lo and behold, it does: I tried most if not all monospaced fonts on my
system (via the set default font menu), and saw the echo area resize
only with these (the first being my default font):

DejaVu Sans Mono
Luxi Mono
Nimbus Mono L

With all other fonts I tried, there was no resizing even though the
argument face was bold.

I still have no idea why there's the .emacs/-Q asymmetry.

Steve Berman