From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32777: 27.0.50; window-buffer gets wrong point Date: Sat, 13 Oct 2018 12:19:39 +0300 Message-ID: <83o9byurtg.fsf@gnu.org> References: <83wor12fut.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1539422289 29763 195.159.176.226 (13 Oct 2018 09:18:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 13 Oct 2018 09:18:09 +0000 (UTC) Cc: juri@linkov.net, 32777@debbugs.gnu.org To: Federico Tedin , martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 13 11:18:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBG3g-0007dC-IB for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2018 11:18:04 +0200 Original-Received: from localhost ([::1]:44278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBG5n-0006xC-4l for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Oct 2018 05:20:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBG5h-0006vA-3g for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 05:20:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBG5d-0004d2-VR for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 05:20:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43477) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gBG5a-0004U6-1h for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 05:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gBG5Z-0008BI-S5 for bug-gnu-emacs@gnu.org; Sat, 13 Oct 2018 05:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Oct 2018 09:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32777-submit@debbugs.gnu.org id=B32777.153942238431420 (code B ref 32777); Sat, 13 Oct 2018 09:20:01 +0000 Original-Received: (at 32777) by debbugs.gnu.org; 13 Oct 2018 09:19:44 +0000 Original-Received: from localhost ([127.0.0.1]:47735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBG5H-0008Ah-Ns for submit@debbugs.gnu.org; Sat, 13 Oct 2018 05:19:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43335) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gBG5F-0008AU-Sh for 32777@debbugs.gnu.org; Sat, 13 Oct 2018 05:19:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBG59-00047T-PW for 32777@debbugs.gnu.org; Sat, 13 Oct 2018 05:19:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBG59-00047D-HW; Sat, 13 Oct 2018 05:19:35 -0400 Original-Received: from [176.228.60.248] (port=3547 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gBG57-0006d5-W8; Sat, 13 Oct 2018 05:19:35 -0400 In-reply-to: (message from Federico Tedin on Tue, 2 Oct 2018 09:31:25 -0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151203 Archived-At: > From: Federico Tedin > 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?