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

Previous Next

Full log

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.