GNU bug report logs - #33424
pop-to-buffer-same-window in emacs 26-1

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33424 in the body.
You can then email your comments to 33424 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Steve Schooler <sgschooler <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: pop-to-buffer-same-window in emacs 26-1
Date: Sun, 18 Nov 2018 15:54:54 -0800

[Message part 1 (text/plain, inline)]

Please see
https://emacs.stackexchange.com/questions/46072/emacs-26-1-problems-find-file-and-neotree

[Message part 2 (text/html, inline)]

Message #8 received at 33424 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steve Schooler <sgschooler <at> gmail.com>
Cc: 33424 <at> debbugs.gnu.org
Subject: Re: bug#33424: pop-to-buffer-same-window in emacs 26-1
Date: Mon, 19 Nov 2018 17:59:02 +0200

tags 33424 notabug
thanks

> From: Steve Schooler <sgschooler <at> 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.

Message #15 received at 33424-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steve Schooler <sgschooler <at> gmail.com>
Cc: 33424-done <at> debbugs.gnu.org
Subject: Re: bug#33424: pop-to-buffer-same-window in emacs 26-1
Date: Tue, 20 Nov 2018 17:47:59 +0200

[Please use "Reply to All" to reply to these messages, otherwise you
are only replying to myself.]

> From: Steve Schooler <sgschooler <at> gmail.com>
> Date: Mon, 19 Nov 2018 13:18:53 -0800
> 
> Thank you very much for the thorough analysis.  I just installed the latest version of neotree, and the behavior
> of emacs 26-1 is just as you described.  This covers most but (perhaps) not all of the bug-issue that I
> suspected.  
> 
> I thought that I had also noticed unusual behavior, where (sometimes) opening a file would result in splitting
> the current frame into 2 windows, rather than dedicating the entire frame to the new file.  Unfortunately, I could
> not detect a pattern to this, so I can not report a reproducible situation, EXCEPT FOR ONE THING.
> 
> Suppose that you re-create the situation where at the end of your emacs initialization, you use the find-file
> command to load a few files, then use the neotree command.  You would then be simulating the tail end of my
> initialization.
> 
> Suppose that immediately after emacs comes up, you take the <menu><buffer> menu option to display the
> list of (some of ) the buffers.  If you then mouse-select one of these buffers, the frame will split into two
> windows.  I suspect that this is BECAUSE the pop-to-buffer-same-window function is REGARDING THE
> FRAME AS BELONGING TO NEOTREE.
> 
> This is just a heads-up.  You might reasonably construe this to NOT BE A BUG.  If so, then I think the
> bug-ticket can be closed.  However, this may serve as a warning that in some situations,
> pop-to-buffer-same-window will behave unusually, based on who pop-to-buffer-same-window believes is the
> "owner" of the frame.

If you invoke find-file from the menu bar with the neotree's directory
in the selected window, you will always see this behavior, because
find-file is unable to reuse the selected window, due to its being
dedicated to the neotree buffer.

I'm therefore closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.