bug#12170: save-excursion fails boundary case with recenter

[martin rudalics <rudalics@gmx.at>]

 >>    (defun f (n)
 >>       (save-this-window-excursion (forward-line (- n)) (recenter 0)))
 >>
 >>     (let ((buffer (switch-to-buffer "foo"))
 >>           (height (1- (window-height (get-buffer-window "foo")))))
 >>       (insert-char 10 (* height 2))
 >>       (let ((pt (point)))
 >>         (f height)
 >>         (redisplay)
 >>         (message "height %s old %s new %s" height pt (point)))))
 >>
 >> so I'd suspect the culprit somewhere in redisplay_window's code
 >
 > By saying "culprit" you mean you think this is a bug?

I suppose so, yes.

 > I think Stefan
 > explained why it isn't.

With the OP's last recipe, `point' moves to the position implied by the
`recenter' call.  With the `save-this-window-excursion' macro I gave,
`point' moves to the position implied by that macro instead and the
position implied by the `recenter' call is ignored.  So here something
unexplained happens.

If we wanted to document the current behavior, we'd have to tell users
that if they call any of the window-related movement functions like
`recenter', `move-to-window-line', or `set-window-start' with a nil
NOFORCE argument, then `point' may move after the next redisplay in
order to honor the window start position implied by the last of these
functions executed.  Do you agree so far?

If you agree, then we'd have to explain why a subsequent invocation of
`set-window-start' with NOFORCE t can override the setting of the window
start position implied by the last invocation of one of the functions
mentioned above.

 >> w->force_start 1 will cause redisplay to honor the start position set up
 >> by `recenter'
 >
 > Only if point will be visible when window is displayed starting at
 > startp.

I completely miss you here.

 >> But I don't have the slightest idea how calling
 >>
 >> 	 (set-window-start (selected-window) ,start t)
 >>
 >> would remedy this.  Eli will soon teach us a lesson here.
 >
 > Not sure there's a lesson here to learn, but set-window-start sets the
 > w->force_start flag unconditionally,

IMHO

   if (NILP (noforce))
     w->force_start = 1;

means "conditionally".

 > so it will hold even if point is
 > not in the displayed portion of the window (i.e., point will move).
 > Does that explain things?

Not yet ;-)

martin