bug#33424: pop-to-buffer-same-window in emacs 26-1

[Eli Zaretskii]

tags 33424 notabug
thanks

> From: Steve Schooler <sgschooler@gmail.com>
> 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.