[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#32777: 27.0.50; window-buffer gets wrong point
Date: Sat, 13 Oct 2018 12:19:39 +0300

> From: Federico Tedin <address@hidden>
> Date: Tue, 2 Oct 2018 09:31:25 -0300
> Cc: address@hidden, address@hidden
> > 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.


Martin, any comments?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]