bug#12208: yes-or-no-p escapes with-current-buffer

[Steve Hafner]

On Thu, Aug 16, 2012 at 3:38 AM, martin rudalics <rudalics@gmx.at> wrote:
>> Open two buffers "buffer1" and  "buffer2" so that both are visible.
>>
>> Place the following in each buffer
>>
>> (with-current-buffer "buffer1"
>>         (goto-char (point-min))
>>       (yes-or-no-p "")
>>       (insert "X"))
>>
>> C-xC-e from buffer1 places "X" at the beginning of the file, while
>> C-xC-e from buffer2 places an "X" wherever the point was before moving
>> from buffer1. This doesn't happen if only one buffer is visible; Nor
>> does it happen if we replace "yes-or-no-p" with "y-or-n-p".
>> This happens on both 23.3.1 and 24.1.
>
> Indeed.  What you see is `save-window-excursion' at work.  Let's remove
> `yes-or-no-p' from the example.  With emacs -Q in *scratch* evaluate the
> following form:
>
> (let ((form
>        "(with-current-buffer \"*buffer1*\"
>   (goto-char (point-min))
>   (save-window-excursion
>     nil)
>   (setq x (1+ x))
>   (insert (format \"%s\" x)))"))
>   (setq x 0)
>   (switch-to-buffer (get-buffer-create "*buffer1*"))
>   (insert form)
>   (split-window)
>   (other-window 1)
>   (switch-to-buffer (get-buffer-create "*buffer2*"))
>   (insert form)
>   (other-window 1))
>
> Now in any of the two windows go to the end of the buffer and evaluate
> the preceding form.  From the *buffer1* window the number is inserted at
> position 1, from the *buffer2* window at the position of *buffer1*
> before evaluating the form.  If, instead, you used the slightly
> different form
>
> (let ((form
>        "(with-selected-window (get-buffer-window \"*buffer1*\")
>   (goto-char (point-min))
>   (save-window-excursion
>     nil)
>   (setq x (1+ x))
>   (insert (format \"%s\" x)))"))
>   (setq x 0)
>   (switch-to-buffer (get-buffer-create "*buffer1*"))
>   (insert form)
>   (split-window)
>   (other-window 1)
>   (switch-to-buffer (get-buffer-create "*buffer2*"))
>   (insert form)
>   (other-window 1))
>
> both insertions happen at position 1.
>
> martin

Thanks for the examples. If I understand correctly,
save-window-excursion ends with among other things restoring the
window points; and each time a window point is set, the buffer point
is set as well. And while the current buffer is restored,
save-window-excursion does not restore the point in the current
buffer, leaving it at the position set by the window point restore, if
there was one. What I don't understand is the rationale for not
restoring the current buffer point. Perhaps it's just windows have
precedence in a restore.

Steve