Re: Why should it be so hard to tell find-dired to use a different window?

Re: Why should it be so hard to tell find-dired to use a different window?

[Trevor Murphy]

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

> There's pop-to-buffer-same-window.
>
>> Is there any particular reason to keep using switch-to-buffer 
>> here?
>
> AFAIK the only reason is history

Alright, well, I mean I’ve already signed over my copyright to FSF 
and this is a super small change.  Here’s the obvious patch, I 
hope it gets applied.

I don’t think it can negatively affect anybody’s quality of life. 
I don’t see any calls to find-dired and friends in the stock Emacs 
codebase, I don’t see any calls in major packages I might expect 
to use dired under the hood (e.g. neotree), and so I’d only worry 
about interactive use of the command.  But then without additional 
customization p-t-b-s-w should behave the same as s-t-b.

Then on the positive side this would allow customization if folks 
(like me) use find-dired and friends on a regular basis.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-user-customization-to-affect-display-of-Find-b.patch --]
[-- Type: text/x-patch, Size: 900 bytes --]

From 51ce5d68a2a6e870dfbb7b8839d0d45489effc85 Mon Sep 17 00:00:00 2001
From: Trevor Murphy <trevor.m.murphy@gmail.com>
Date: Sat, 22 Sep 2018 16:42:20 -0700
Subject: [PATCH] Allow user customization to affect display of *Find* buffer.

* lisp/find-dired.el (find-dired): Change buffer display function.
---
 lisp/find-dired.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/find-dired.el b/lisp/find-dired.el
index ebd14b0757..9a798b0e39 100644
--- a/lisp/find-dired.el
+++ b/lisp/find-dired.el
@@ -144,7 +144,7 @@ find-dired
     ;; Check that it's really a directory.
     (or (file-directory-p dir)
 	(error "find-dired needs a directory: %s" dir))
-    (switch-to-buffer (get-buffer-create "*Find*"))
+    (pop-to-buffer-same-window (get-buffer-create "*Find*"))
 
     ;; See if there's still a `find' running, and offer to kill
     ;; it first, if it is.
-- 
2.19.0

Re: Why should it be so hard to tell find-dired to use a different window?

[Eli Zaretskii]

> From: Trevor Murphy <trevor.m.murphy@gmail.com>
> Date: Sat, 22 Sep 2018 17:20:58 -0700
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Alright, well, I mean I’ve already signed over my copyright to FSF 
> and this is a super small change.  Here’s the obvious patch, I 
> hope it gets applied.
> 
> I don’t think it can negatively affect anybody’s quality of life. 
> I don’t see any calls to find-dired and friends in the stock Emacs 
> codebase, I don’t see any calls in major packages I might expect 
> to use dired under the hood (e.g. neotree), and so I’d only worry 
> about interactive use of the command.  But then without additional 
> customization p-t-b-s-w should behave the same as s-t-b.
> 
> Then on the positive side this would allow customization if folks 
> (like me) use find-dired and friends on a regular basis.

Thanks, pushed to the master branch.

Why should it be so hard to tell find-dired to use a different window?

[Trevor Murphy]

I just noticed that `find-dired' and friends use 
`switch-to-buffer' as a subroutine.  Since this does not go 
through the `display-buffer' mechanism, it’s really hard for me to 
control where Emacs displays the Find buffer.  I’m currently 
advising `find-dired' to use `pop-to-buffer' instead.

I’m surprised that it works this way?  Does this bother anybody 
else?

Like, I could imagine an alternate world where that call to 
`switch-to-buffer' could be replaced with something as 
heavy-handed as …

    (pop-to-buffer (get-buffer-create "*Find*") 
    '(display-buffer-same-window (inhibit-same-window)))

… so that Emacs would still try very hard to display the Find 
buffer in the current window, but I could nevertheless override 
that by customizing `display-buffer-alist'.

Is there any particular reason to keep using switch-to-buffer 
here?

Re: Why should it be so hard to tell find-dired to use a different window?

[Stefan Monnier]

> I’m surprised that it works this way?  Does this bother anybody else?

I've been in this fight for a long time, but since I don't use
find-fired, I haven't bumped into this problem.

> Like, I could imagine an alternate world where that call to
> `switch-to-buffer' could be replaced with something as heavy-handed as …
>
>    (pop-to-buffer (get-buffer-create "*Find*")  '(display-buffer-same-window
> (inhibit-same-window)))

There's pop-to-buffer-same-window.

> Is there any particular reason to keep using switch-to-buffer here?

AFAIK the only reason is history,


        Stefan

Re: Why should it be so hard to tell find-dired to use a different window?

[Stephen Leake]

Trevor Murphy <trevor.m.murphy@gmail.com> writes:

> I just noticed that `find-dired' and friends use `switch-to-buffer' as
> a subroutine.  Since this does not go through the `display-buffer'
> mechanism, it’s really hard for me to control where Emacs displays the
> Find buffer.  I’m currently advising `find-dired' to use
> `pop-to-buffer' instead.

See the Gnu ELPA package 'other-frame-window'; it addresses this issue
in a more general way.

> I’m surprised that it works this way?  Does this bother anybody else?

Yes, which is why I wrote that package, with help from Stefan Monnier.

> Like, I could imagine an alternate world where that call to
> `switch-to-buffer' could be replaced with something as heavy-handed as
> …
>
>    (pop-to-buffer (get-buffer-create "*Find*")
> '(display-buffer-same-window (inhibit-same-window)))

That's essentially what 'other-frame-window' does, as well as defining
prefix keys for other-frame and other-window.

> Is there any particular reason to keep using switch-to-buffer here?

No, but it's hard fighting inertia.

-- 
-- Stephe