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#33424: pop-to-buffer-same-window in emacs 26-1 Date: Mon, 19 Nov 2018 17:59:02 +0200 Message-ID: <83wop9rrcp.fsf@gnu.org> References: NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1542643314 19939 195.159.176.226 (19 Nov 2018 16:01:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2018 16:01:54 +0000 (UTC) Cc: 33424@debbugs.gnu.org To: Steve Schooler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 19 17:01:49 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 1gOlzh-00052K-GI for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Nov 2018 17:01:49 +0100 Original-Received: from localhost ([::1]:57420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOm1n-0007te-Pm for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Nov 2018 11:03:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOly1-0004XZ-Rc for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 11:00:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gOlxy-0007oh-Kc for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 11:00:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56832) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gOlxy-0007oc-H4 for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 11:00:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gOlxy-00039J-Bm for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 11:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Nov 2018 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33424 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33424-submit@debbugs.gnu.org id=B33424.154264315812011 (code B ref 33424); Mon, 19 Nov 2018 16:00:02 +0000 Original-Received: (at 33424) by debbugs.gnu.org; 19 Nov 2018 15:59:18 +0000 Original-Received: from localhost ([127.0.0.1]:32856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gOlxF-00037f-PI for submit@debbugs.gnu.org; Mon, 19 Nov 2018 10:59:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gOlxE-00037S-1t for 33424@debbugs.gnu.org; Mon, 19 Nov 2018 10:59:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gOlx5-0007So-NK for 33424@debbugs.gnu.org; Mon, 19 Nov 2018 10:59:10 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOlwv-0007PC-Bc; Mon, 19 Nov 2018 10:58:57 -0500 Original-Received: from [176.228.60.248] (port=3938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gOlwv-0003VX-01; Mon, 19 Nov 2018 10:58:57 -0500 In-reply-to: (message from Steve Schooler on Sun, 18 Nov 2018 15:54:54 -0800) 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:152535 Archived-At: tags 33424 notabug thanks > From: Steve Schooler > Date: Sun, 18 Nov 2018 15:54:54 -0800 > > Please see https://emacs.stackexchange.com/questions/46072/emacs-26-1-problems-find-file-and-neotree Thanks, but please in the future describe the issue in detail here. I will copy the relevant parts of the above URL: > The Problems: > > I just did a full re-install to Fedora 29, which included the dnf install emacs command. This installed emacs 26-1; formerly I was using emacs 25.2. Formerly, my emacs initialization concluded with : > > (neotree-dir "/home/steve/") > ; > (eww-open-file "~/emacs/neotree/EmacsWiki: Neo Tree.html") > (find-file "~/notes/notes_todo.txt") > (find-file "~/emacs/mywork/notes_todo.txt") > (find-file "~/emacs/mywork/elisp_notes_todo.txt") > (find-file "~/notes/notes_movies_to_download.txt") > (find-file "~/notes/notes_watched_tv.txt") > (find-file "~/math/misc/complex_analysis_01.tex") > > In emacs 25.2, this worked fine, with the neotree attached to the frame. In emacs 26-1, the frame is split horizontally into two windows, with the last file opened in the bottom window. Further, when I navigate to the frame's bottom window, and then execute C-x 1 (delete-other-windows), the neotree is also deleted. In emacs 25.2, the neotree would not be deleted here. > > Also, sometimes when I open a file, it splits the frame into two windows rather than simply switching to the new file's buffer. I haven't been able to track down the pattern behind this behavior, so I can't be more precise here. > > My kludgy temporary initialization workaround: > > (eww-open-file "~/emacs/neotree/EmacsWiki: Neo Tree.html") > (find-file "~/notes/notes_todo.txt") > (find-file "~/emacs/mywork/notes_todo.txt") > (find-file "~/emacs/mywork/elisp_notes_todo.txt") > (find-file "~/notes/notes_movies_to_download.txt") > (find-file "~/notes/notes_watched_tv.txt") > (find-file "~/math/misc/complex_analysis_01.tex") > ; > (delete-other-windows) > ; > (neotree-dir "/home/steve/") > > This resolves initialization but does not resolve the subsequent undesired splitting of a frame into windows. Also, it does not resolve preserving neotree when I delete a window from a split frame. > > My Research > > In emacs 25.2, the relevant code was : > > (defun find-file (filename &optional wildcards) > "..." > (interactive > (find-file-read-args "Find file: " > (confirm-nonexistent-file-or-buffer))) > (let ((value (find-file-noselect filename nil nil wildcards))) > (if (listp value) > (mapcar 'switch-to-buffer (nreverse value)) > ;;else : this comment added by me > (switch-to-buffer value)))) > > In emacs 26.1, the relevant code is : > > (defun find-file (filename &optional wildcards) > "..." > (interactive > (find-file-read-args "Find file: " > (confirm-nonexistent-file-or-buffer))) > (let ((value (find-file-noselect filename nil nil wildcards))) > (if (listp value) > (mapcar 'pop-to-buffer-same-window (nreverse value)) > ;;else : this comment added by me > (pop-to-buffer-same-window value)))) > > Either: > 1. I have misunderstood the purpose of (pop-to-buffer-same-window) or > 2. (pop-to-buffer-same-window) is not working as intended. AFAICT, pop-to-buffer-same-window is working as intended. It tries to display the file in the window from which find-file was invoked, but your original code, which called neotree-dir before loading the files, caused find-file to be invoked from the neotree window (to which neotree-dir switches), and that window is dedicated to its buffer. So pop-to-buffer-same-window cannot reuse that window for another buffer, and it therefore uses a different window (in this case, creating a new one). Your workaround is actually what I would recommend as _the_ solution: call neotree-dir after loading all of the files (there's no need for deleting the other windows, at least not in my testing). That will invoke find-file from a non-dedicated window, and will work as you expect. IOW, your original code relied on undocumented behavior of find-file when invoked from a window that is dedicated to its buffer. That undocumented behavior was changed to another undocumented behavior, the only documented aspect of which is that find-file uses some other window in this case; it is unspecified which window exactly. Also, I cannot reproduce this part: > Further, when I navigate to the frame's bottom window, and then execute C-x 1 (delete-other-windows), the neotree is also deleted. In my testing, the neotree window is not deleted by "C-x 1", as I'd expect, because it has its no-delete-other-windows parameter set to a non-nil value. Maybe your neotree installation is outdated? (I tried the latest version.) Or maybe some other local customizations cause this? Bottom line, I see no bugs here. It is all intended and correct behavior.