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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 17 May 2010 20:02:22 +0200
> Cc: monnier@iro.umontreal.ca, stephen.berman@gmx.net, 6192@debbugs.gnu.org
> 
> On Mon, May 17, 2010 at 7:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > When Emacs recenters, that means it exhausted all the other available
> > redisplay optimizations, and fell back on its default method of
> > completely redrawing a window.
> >
> > What you want is an optimization that does not yet exist, AFAIK.  It
> > needs to be designed and coded.  The tricky part is to detect the
> > situation where the amount of scrolling can be easily computed in
> > advance, and do that computation without too many complications.  You
> > seem to think that this computation is easy, but that is only true
> > when the display shows characters of the same size everywhere.  In the
> > more general case, what do we do? still recenter?
> 
> 
> Would it be possible to try 1 line scrolling first, then 2 etc?

Maybe we could, but that would be slow, I think.  Don't forget that
there could be more than one window affected by resizing.  And since
redisplay in general works on each window independently, tieing
together redispay of the echo area and the windows above the mode line
would be a complication.  Is it really worth that?

Also, note that scrolling only by the minimum amount will cause
annoying jumpy display if some command repeatedly displays messages of
different length in the echo area.  Recentering once avoids that to a
large degree, because it more often than not will scroll just once.

In general, my advice to people who are annoyed by recentering to set
resize-mini-windows to nil (among other things).

But if someone wants to work on a redisplay optimization that would
favor such scrolling, feel free.