unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#33424: pop-to-buffer-same-window in emacs 26-1
@ 2018-11-18 23:54 Steve Schooler
  2018-11-19 15:59 ` Eli Zaretskii
  0 siblings, 1 reply; 3+ messages in thread
From: Steve Schooler @ 2018-11-18 23:54 UTC (permalink / raw)
  To: 33424

[-- Attachment #1: Type: text/plain, Size: 101 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 251 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#33424: pop-to-buffer-same-window in emacs 26-1
  2018-11-18 23:54 bug#33424: pop-to-buffer-same-window in emacs 26-1 Steve Schooler
@ 2018-11-19 15:59 ` Eli Zaretskii
       [not found]   ` <CAOxkcC6T_d6EfvsX4fGREik8qAQ_xk8OL1c9E8zX88QLqGh2zQ@mail.gmail.com>
  0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2018-11-19 15:59 UTC (permalink / raw)
  To: Steve Schooler; +Cc: 33424

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.





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#33424: pop-to-buffer-same-window in emacs 26-1
       [not found]   ` <CAOxkcC6T_d6EfvsX4fGREik8qAQ_xk8OL1c9E8zX88QLqGh2zQ@mail.gmail.com>
@ 2018-11-20 15:47     ` Eli Zaretskii
  0 siblings, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2018-11-20 15:47 UTC (permalink / raw)
  To: Steve Schooler; +Cc: 33424-done

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

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





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-11-20 15:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-11-18 23:54 bug#33424: pop-to-buffer-same-window in emacs 26-1 Steve Schooler
2018-11-19 15:59 ` Eli Zaretskii
     [not found]   ` <CAOxkcC6T_d6EfvsX4fGREik8qAQ_xk8OL1c9E8zX88QLqGh2zQ@mail.gmail.com>
2018-11-20 15:47     ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).