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

[Stephen Berman]

On Sat, 15 May 2010 00:05:52 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Fri, 14 May 2010 19:11:30 +0200
>> 
>> => This puts point at line 902 (at least here, with window-height 33),
>> which is at the bottom of the window as it should be -- but only for a
>> fraction of a second, and then point is recentered so that line 902 is
>> now in the middle of the window.
>
> I cannot reproduce this on MS-Windows.  In my case, M-v from the end
> of the buffer puts point on line 902, but it is the second line from
> the bottom of the window, not the first.  

Yes, my OP was inaccurate, M-v does put point on the penultimate line.
Sorry for the sloppiness.

>                                           And even if I then type C-n,
> point stays on the last line.  I see no recentering at all.

Maybe it's a GTK+ issue.  (I just checked and I don't see the
recentering when I start Emacs with -nw)

> 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 M-v puts point inside a string or on an empty line between
sexp's, then there is no recentering (and the minibuffer clears and
returns to one line).  That seems significant...

> Do you see the same problem in Emacs 23.2?

I don't have 23.2, but I do have GNU Emacs 23.1.91.4 (i686-pc-linux-gnu,
GTK+ Version 2.18.1) of 2010-01-28 on escher, and I observe the
recentering with this build as well.

Thanks for the feedback.

Steve Berman