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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 11 Aug 2012 18:10:26 +0300

> Date: Sat, 11 Aug 2012 16:22:39 +0200
> From: martin rudalics <[email-masked]>
> CC: [email-masked], [email-masked]
> 
> (progn
>    (defmacro save-this-window-excursion (&rest body)
>      "..."
>      (let ((start (make-symbol "start"))
>        (point (make-symbol "point")))
>        `(let ((,start (copy-marker (window-start)))
>           (,point (copy-marker (window-point))))
>       (save-selected-window
>         (progn ,@body))
>       (set-window-start (selected-window) ,start t)
>       (with-current-buffer (window-buffer (selected-window))
>         (goto-char ,point)))))
> 
>    (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)))))
> 
> I get the same results as with `set-window-point'.  IMHO the
> `set-window-start' call makes the difference but I don't understand why.

Maybe.  If it's really important, I could try looking at this in the
debugger, although doing so to investigate such situations is
notoriously hard, because redisplay is entered several times.

IMO, save-excursion is simply not designed to make sure display isn't
changed in such cases.  It's for excursions into other portions of the
buffer for processing those other parts, without affecting display.
If the processing also scrolls the screen or calls recenter or
otherwise affects the display, all bets are off, because scrolling can
legitimately move point, and when that happens, it is no longer clear
that restoring point should take precedence over window-start etc.