Re: delete-overlay causes recentering

[Chong Yidong <cyd@stupidchicken.com>]

Richard Stallman <rms@gnu.org> writes:

>     When a window starts is in a continued line, it is recentered whenever
>     the window is unselected--by activating the minibuffer, switching to
>     another window, or switching to another frame.
>
> That is the spurious scrolling bug I have mentioned.  Thank you
> for connecting it with specific code.  Now it should be possible
> to track it down.
>
> Yidong wrote:
>
>     I don't know an easy way to fix this.
>
> Can you describe the series of events that cause the
> spurious recentering?

KFS described the problem in the original change that led to this:

  When the filling command has reformatted the buffer text, the
  redisplay code still starts window display at the old window start
  -- which still is in the middle of a line, but not at the same
  relative position in the line as before ... so it gets confused.

  This is just one way in which a buffer change can mess things up
  when window start is not at the start of a line, so I think it is
  generally a bit difficult to find a method which will always select
  the intuitively best window start after such a change.

As a result, there will be times when the redisplay engine must
recenter, simply to avoid screen corruption.

On the other hand, I just realized that the "recentering due to
minibuffer-activation" problem is a simple oversight on my part, when
I was fixing the recentering to make it less aggressive.  I've checked
in a small fix.