bug#32777: 27.0.50; window-buffer gets wrong point

[Eli Zaretskii]

> From: Federico Tedin <federicotedin@gmail.com>
> Date: Tue, 2 Oct 2018 09:31:25 -0300
> Cc: juri@linkov.net, 32777@debbugs.gnu.org
> 
> > Can you explain the change?  The minibuffer window is already the
> > selected window at this point (look at the implementation of
> > minibuffer-selected-window), so using with-selected-window, which
> > seems to be the only real change in the above, should be redundant.
> 
> This was my reasoning:
> 
> Calling "minibuffer-selected-window" returns the last selected window
> before switching to the minibuffer. Then, calling "window-buffer" with
> that window will return that window's buffer.
> 
> The problem is that when "with-current-buffer" is called with the
> resulting buffer, it that buffer has been opened on more than one
> window, the active window will be set according to a criteria which I
> haven't figured out yet, but not necessarily to the same exact window
> "minibuffer-selected-window" returned.
> 
> The way I tested this was the following:
> 1) On a frame, open three windows. On the first two, open *scratch*.
> On the third one, open
> any other buffer.
> 2) Insert some content into buffer *scratch* ("hello").
> 3) Make sure the first window is selected, and move the point to (point-min).
> 4) M-x eval-expression (with-current-buffer "*scratch*" (message "%s"
> (point))) should yield "1".
> 5) Select the second window, and move the point to (point-max).
> 6) M-x eval-expression (with-current-buffer "*scratch*" (message "%s"
> (point))) should yield "7".
> 7) Now, select the third window.
> 8) M-x eval-expression (with-current-buffer "*scratch*" (message "%s" 
> (point)))
> 
> The last point yields "1" in my case. If I wanted it to yield "7", I
> would have to explicitly select the second window.  So from this, I
> reasoned that using M-n when in read-extended-command, it will try to
> read a command from the last selected window's buffer, but the value
> of the point can vary if there's more than one window visiting that
> buffer (like in the test case originally described by Juri). Please
> correct me if I'm wrong.

Thanks.

Martin, any comments?