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

[Stephen Berman <stephen.berman@gmx.net>]

On Sat, 15 May 2010 09:36:55 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 6192@debbugs.gnu.org
>> Date: Fri, 14 May 2010 23:44:06 +0200
>> 
>> > Anyway, from what you say it sounds like the message displayed by
>> > eldoc-mode in the echo area, which causes redisplay, somehow makes
>> > Emacs think the window where you have the Lisp file needs to be
>> > recentered because point is in a line that is not visible enough.
>> 
>> Ah, your reference to the Eldoc message made me take another look, and I
>> think I've now found a pattern: the recentering appears to happen only
>> (and always) when the message is displayed, and then the minibuffer
>> expands to and remains at two lines, even though the message is a single
>> line.
>
> When that happens, do you see any message in *Messages* besides the
> one displayed in the echo area?

Nothing in *Messages* (not even the Eldoc message -- it is deliberately
suppressed by eldoc-message).

> In general, a single-line message should not resize the echo area.  If
> the echo area is resized, then recentering you describe is a normal
> reaction of the display engine.  So the question now is why the echo
> area is enlarged to 2 lines.

I don't know, but I stepped through eldoc.el with Edebug and when it got
to the point where the message is put into the echo area, this is what
it showed:

Result: #("let: (VARLIST BODY...)" 0 3 (face font-lock-function-name-face) 14 21 (face eldoc-highlight-function-argument))

This string made the echo area expand to two lines, but in normal
(non-edebug) execution it of course shows up just as "let: (VARLIST
BODY...)" (with fontification).  So if the propertized string is the
source of the expanded echo area, the question becomes why it does not
shrink again.  (And there's still the question of why this only happens
when eldoc-mode is enabled in my init file...)

Steve Berman