unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Why should it be so hard to tell find-dired to use a different window?
@ 2018-09-21  7:55 Trevor Murphy
  2018-09-21 14:52 ` Stefan Monnier
  2018-09-22 14:25 ` Stephen Leake
  0 siblings, 2 replies; 5+ messages in thread
From: Trevor Murphy @ 2018-09-21  7:55 UTC (permalink / raw)
  To: emacs-devel@gnu.org

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?




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

* Re: Why should it be so hard to tell find-dired to use a different window?
  2018-09-21  7:55 Why should it be so hard to tell find-dired to use a different window? Trevor Murphy
@ 2018-09-21 14:52 ` Stefan Monnier
  2018-09-22 14:25 ` Stephen Leake
  1 sibling, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2018-09-21 14:52 UTC (permalink / raw)
  To: emacs-devel

> 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




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

* Re: Why should it be so hard to tell find-dired to use a different window?
  2018-09-21  7:55 Why should it be so hard to tell find-dired to use a different window? Trevor Murphy
  2018-09-21 14:52 ` Stefan Monnier
@ 2018-09-22 14:25 ` Stephen Leake
  1 sibling, 0 replies; 5+ messages in thread
From: Stephen Leake @ 2018-09-22 14:25 UTC (permalink / raw)
  To: emacs-devel

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



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

* Re: Why should it be so hard to tell find-dired to use a different window?
@ 2018-09-23  0:20 Trevor Murphy
  2018-09-29  6:40 ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Trevor Murphy @ 2018-09-23  0:20 UTC (permalink / raw)
  To: monnier; +Cc: emacs-devel@gnu.org

[-- 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


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

* Re: Why should it be so hard to tell find-dired to use a different window?
  2018-09-23  0:20 Trevor Murphy
@ 2018-09-29  6:40 ` Eli Zaretskii
  0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2018-09-29  6:40 UTC (permalink / raw)
  To: Trevor Murphy; +Cc: monnier, emacs-devel

> 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.



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

end of thread, other threads:[~2018-09-29  6:40 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-09-21  7:55 Why should it be so hard to tell find-dired to use a different window? Trevor Murphy
2018-09-21 14:52 ` Stefan Monnier
2018-09-22 14:25 ` Stephen Leake
  -- strict thread matches above, loose matches on Subject: below --
2018-09-23  0:20 Trevor Murphy
2018-09-29  6:40 ` 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).