GNU bug report logs - #15504
24.3; find-dired's numerous prompts are inflexible and annoying

Previous Next

Package: emacs;

Reported by: trentbuck <at> gmail.com (Trent W. Buck)

Date: Wed, 2 Oct 2013 01:46:02 UTC

Severity: wishlist

Found in version 24.3

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#15504; Package emacs. (Wed, 02 Oct 2013 01:46:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to trentbuck <at> gmail.com (Trent W. Buck):
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 02 Oct 2013 01:46:02 GMT) Full text and rfc822 format available.

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

From: trentbuck <at> gmail.com (Trent W. Buck)
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; find-dired's numerous prompts are inflexible and annoying
Date: Wed, 02 Oct 2013 11:45:16 +1000
I prefer to do M-x grep RET and then type something complicated like

    grep -r --include '*.c' --exclude-dir .git . -e foo -e bar

...rather than M-x rgrep which has lots of stupid prompts that then get
stuck together in a fixed kind of way.

In the same vein, I hate M-x find dired RET multiple prompts.  For a few
years I've been using a munged up replacement that just asks for a
single command, and runs it (below).  The history handling is a bit
buggered, and it breaks the existing multi-prompt style (presumably some
people prefer it).

Daniel Colascione liked my approach and asked me to publish it,
(presumably) so it can be cleaned up and pushed into Emacs proper.
I don't care enough to do that work myself, but I'm happy to talk to
anyone who does.  I've already done the copyright assignment dance.

PS: find -ls's output is actually crap, because the entries don't line
up properly and files with spaces become "foo\ bar" which dired mode
doesn't like, so I generally end up doing "find -exec ls -lidsh {} +".


(setq
 find-ls-option                         ; http://emacsbugs.donarmstrong.com/4403
 (let ((help (shell-command-to-string (format "%s --help" find-program))))
   (if (string-match " -ls\\>" help)
       '("-ls" . "-lids")
     (if (string-match "{} \\+" help)
         '("-exec ls -ldh {} +" . "-ldh")
       '("-exec ls -ldh {} \\;" . "-ldh")))))

;;; Guerilla patch -- redefine FIND-DIRED to act less like RGREP and more like
;;; GREP.  That is, prompt for an arbitrary command instead of "helpfully"
;;; constructing a command from an inflexible series of prompts.  Defaults to
;;; "find -ls"; "find -exec ls {} +" is also possible to e.g. sort by file size.
(eval-after-load "dired"
  '(eval-after-load "find-dired"
     '(progn
        (defvar find-command/twb (concat find-program " " (car find-ls-option)))
        (defvar find-command-history/twb nil)
        (defun find-dired (command)
          "Like find-dired, but let me just WRITE the command instead of
trying to construct it for me.  Cf. `grep' vs. `rgrep'."
          (interactive (list (read-string "Run find: " find-command/twb '(find-command-history/twb . 1))))
          (let ((dired-buffers dired-buffers)
                (dir default-directory))
            (switch-to-buffer (get-buffer-create "*Find*"))
            (setq default-directory dir)

            ;; See if there's still a `find' running, and offer to kill
            ;; it first, if it is.
            (let ((find (get-buffer-process (current-buffer))))
              (when find
                (if (or (not (eq (process-status find) 'run))
                        (yes-or-no-p "A `find' process is running; kill it? "))
                    (condition-case nil
                        (progn
                          (interrupt-process find)
                          (sit-for 1)
                          (delete-process find))
                      (error nil))
                  (error "Cannot have two processes in `%s' at once" (buffer-name)))))

            (widen)
            (kill-all-local-variables)
            (setq buffer-read-only nil)
            (erase-buffer)
            (setq find-command command) ; save for next interactive call
            ;; Start the find process.
            (shell-command (concat command "&") (current-buffer))
            ;; The next statement will bomb in classic dired (no optional arg allowed)
            (dired-mode default-directory (cdr find-ls-option))
            (let ((map (make-sparse-keymap)))
              (set-keymap-parent map (current-local-map))
              (define-key map "\C-c\C-k" 'kill-find)
              (use-local-map map))
            (make-local-variable 'dired-sort-inhibit)
            (setq dired-sort-inhibit t)
            (set (make-local-variable 'revert-buffer-function)
                 `(lambda (ignore-auto noconfirm)
                    (find-dired ,find-command)))
            ;; Set subdir-alist so that Tree Dired will work:
            (if (fboundp 'dired-simple-subdir-alist)
                ;; will work even with nested dired format (dired-nstd.el,v 1.15
                ;; and later)
                (dired-simple-subdir-alist)
              ;; else we have an ancient tree dired (or classic dired, where
              ;; this does no harm)
              (set (make-local-variable 'dired-subdir-alist)
                   (list (cons default-directory (point-min-marker)))))
            (set (make-local-variable 'dired-subdir-switches) find-ls-subdir-switches)
            (setq buffer-read-only nil)
            ;; Subdir headlerline must come first because the first marker in
            ;; subdir-alist points there.
            (insert "  " default-directory ":\n")
            ;; Make second line a ``find'' line in analogy to the ``total'' or
            ;; ``wildcard'' line.
            (insert "  " command "\n")
            (setq buffer-read-only t)
            (let ((proc (get-buffer-process (current-buffer))))
              (set-process-filter proc (function find-dired-filter))
              (set-process-sentinel proc (function find-dired-sentinel))
              ;; Initialize the process marker; it is used by the filter.
              (move-marker (process-mark proc) 1 (current-buffer)))
            (setq mode-line-process '(":%s")))))))




In GNU Emacs 24.3.1 (armv7l-unknown-linux-gnueabi)
 of 2013-03-15 on elba
System Description:	Ubuntu 11.10

Configured using:
 `configure '--without-x' '--without-sound' '--without-all'
 '--with-x-toolkit=no' '--with-xpm=no' '--with-gif=no' '--with-jpeg=no'
 '--with-tiff=no' '--with-png=no' '--with-dbus=no' '--with-gsettings=no'
 '--with-gnutls=no' '--prefix=/home/twb/opt/emacs-24.3''




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#15504; Package emacs. (Fri, 04 Oct 2013 04:18:02 GMT) Full text and rfc822 format available.

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

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15504: 24.3; find-dired's numerous prompts are inflexible
 and annoying
Date: Thu, 03 Oct 2013 22:16:34 -0600
On 10/1/13 7:45 PM, Trent W. Buck wrote:
> I prefer to do M-x grep RET and then type something complicated like
>
>      grep -r --include '*.c' --exclude-dir .git . -e foo -e bar
>
> ...rather than M-x rgrep which has lots of stupid prompts that then get
> stuck together in a fixed kind of way.
>
> In the same vein, I hate M-x find dired RET multiple prompts.  For a few
> years I've been using a munged up replacement that just asks for a
> single command, and runs it (below).  The history handling is a bit
> buggered, and it breaks the existing multi-prompt style (presumably some
> people prefer it).

I'm afraid I don't get what you're saying, since `M-x find-dired' only prompts
for the directory to search and the long string of arguments you love to type:

	find-dired is an interactive autoloaded Lisp function in
	`find-dired.el'.
	
	(find-dired DIR ARGS)
	
	Run `find' and go into Dired mode on a buffer of the output.
	The command run (after changing into DIR) is
	
	    find . \( ARGS \) -ls
	
	except that the variable `find-ls-option' specifies what to use
	as the final argument.

And the implementation confirms the documentation:

	(defun find-dired (dir args)
	...
	  (interactive (list (read-file-name "Run find in directory: " nil "" t)
			     (read-string "Run find (with args): " find-args
					  '(find-args-history . 1))))

...

> PS: find -ls's output is actually crap, because the entries don't line
> up properly and files with spaces become "foo\ bar" which dired mode
> doesn't like, so I generally end up doing "find -exec ls -lidsh {} +".

Apparently that is what `find-ls-option' is for.

-- 
Kevin Rodgers
Denver, Colorado, USA





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#15504; Package emacs. (Sun, 30 May 2021 05:56:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Cc: 15504 <at> debbugs.gnu.org
Subject: Re: bug#15504: 24.3; find-dired's numerous prompts are inflexible
 and annoying
Date: Sun, 30 May 2021 07:55:39 +0200
Kevin Rodgers <kevin.d.rodgers <at> gmail.com> writes:

> I'm afraid I don't get what you're saying, since `M-x find-dired' only prompts
> for the directory to search and the long string of arguments you love to type:

So I don't think there's anything to fix here, and I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 15504 <at> debbugs.gnu.org and trentbuck <at> gmail.com (Trent W. Buck) Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 30 May 2021 05:56:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#15504; Package emacs. (Sun, 30 May 2021 11:42:01 GMT) Full text and rfc822 format available.

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

From: "Trent W. Buck" <trentbuck <at> gmail.com>
To: 15504 <at> debbugs.gnu.org
Subject: Re: bug#15504: 24.3; find-dired's numerous prompts are inflexible
 and annoying
Date: Sun, 30 May 2021 21:41:25 +1000
I'm fine with the "no bug here, closing".
Below is some context / brainstorming / waffling, for the record.


I had a look back to try to remember why I wrote this code originally.
I think it was some combination of these things:

  1. two prompt means two separate history lists.  This annoys/annoyed me.

  2. find-ls-option didn't support -ls, so was really slow on really large finds
     (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=4403)

  3. can ONLY run find, so can't do things like

        # find is too slow, use a cached version
        locate '*.gif' -i0 | xargs -0 ls -hlds

     or

        # find over NFS is too slow, run find on the NFS server
        # (but let Emacs use NFS, not ssh)
        ssh nfs-server find $PWD ...

     or

        # Read from custom metadata that requires expensive ffprobe(1)
        sqlite3 videos.db 'SELECT path FROM videos
                            WHERE duration >60
                              AND rating >=4
                              AND last_seen < julianday()-365' |
        xargs -d\\n ls -hlds |
        shuf


  4. because it's enclosed in \( \), can't "end" with an '-o' or ',',

        find -delete -o -ls     # list file my user can't delete
        find -readable -o -ls   # list files my user can't read

     without reordering the logic, which can be a little annoying for very queries.

  5. can't add things like |sort or |tac to the end, so that the page
     takes time to appear, but when it does, is in a more useful state.

     In Emacs 27+ by default find-dired-refine-function behaves similar to
     adding |sort, except it kicks in when find terminates -- which is usually
     after I've started operating on the first few files, so I end up super confused.

     Actually 99% of the time what I would do is delegate this to ls
     (and hope I didn't have too many files to fit a single ls
     execution).  e.g.

     find -ls
     # ugh this isn't sorted, because ZFS
     M-x <up> RET <up>, change -ls to -exec ls -hlds {} +
     # actually I only care about the biggest files.
     M-x <up> RET <up>, add -Sr
     # wow that's a lot, let's filter it down
     M-x <up> RET <up>, add -size +128M
     # actually I only care about files PHP can see
     M-x <up> RET <up> C-a sudo -u nginx -g www-data RET

Thinking back on all this, what I want is not to run an arbitrary *find* command.
I want to run an *entirely* arbitrary command, and have dired colorize and buttonize the filenames.
The same way I use M-x grep RET with git-grep, not grep.
The same way I add -*-compilation-*- to script(1) files, even though M-x compilation didn't generate them.

I think the two-argument find-dired that's in upstream currently is "good enough" for about 80% of my usage, but
there's lot of niggling edge cases where I can't go "oh I'll just tweak the command" because
find-dired doesn't expose that to me.

Looking at the code again today, the reason WHY is pretty obvious -- dired-mode needs to know
1) default-directory; and 2) the format ls format to parse.

compilation-mode has the same issue for (1) and I solve that by just
putting it in the modeline (IIRC):

    -*-mode:compilation; default-directory:"/rsync:build-server:/var/tmp/buildd/frobozz-1234/"-*-

I haven't really solved (2), I've always just sorta ignored it :-(

Kevin Rodgers wrote:
> On 10/1/13 7:45 PM, Trent W. Buck wrote:
> > I prefer to do M-x grep RET and then type something complicated like
> >
> >      grep -r --include '*.c' --exclude-dir .git . -e foo -e bar
> >
> > ...rather than M-x rgrep which has lots of stupid prompts that then get
> > stuck together in a fixed kind of way.
> >
> > In the same vein, I hate M-x find dired RET multiple prompts.  For a few
> > years I've been using a munged up replacement that just asks for a
> > single command, and runs it (below).  The history handling is a bit
> > buggered, and it breaks the existing multi-prompt style (presumably some
> > people prefer it).
>
> I'm afraid I don't get what you're saying, since `M-x find-dired' only prompts
> for the directory to search and the long string of arguments you love to type:
>
>       find-dired is an interactive autoloaded Lisp function in
>       `find-dired.el'.
>
>       (find-dired DIR ARGS)
>
>       Run `find' and go into Dired mode on a buffer of the output.
>       The command run (after changing into DIR) is
>
>           find . \( ARGS \) -ls
>
>       except that the variable `find-ls-option' specifies what to use
>       as the final argument.



> And the implementation confirms the documentation:
>
>       (defun find-dired (dir args)
>       ...
>         (interactive (list (read-file-name "Run find in directory: " nil "" t)
>                            (read-string "Run find (with args): " find-args
>                                         '(find-args-history . 1))))
>
> ...
>
> > PS: find -ls's output is actually crap, because the entries don't line
> > up properly and files with spaces become "foo\ bar" which dired mode
> > doesn't like, so I generally end up doing "find -exec ls -lidsh {} +".
>
> Apparently that is what `find-ls-option' is for.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#15504; Package emacs. (Sun, 30 May 2021 12:31:02 GMT) Full text and rfc822 format available.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: "Trent W. Buck" <trentbuck <at> gmail.com>
Cc: 15504 <at> debbugs.gnu.org
Subject: Re: bug#15504: 24.3; find-dired's numerous prompts are inflexible
 and annoying
Date: Sun, 30 May 2021 14:30:12 +0200
"Trent W. Buck" <trentbuck <at> gmail.com> writes:

> I'm fine with the "no bug here, closing".
> Below is some context / brainstorming / waffling, for the record.
> [...]

For repeated calls with slightly different parameters I rather use
`repeat-complex-command' instead of the command itself.

Apart from that detail: would it make sense to provide a more general
command that allows to view the output of any shell command to be viewed
as a dired buffer, or something like that, to get rid of the
restrictions?  Or what would you suggest instead?

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#15504; Package emacs. (Sun, 30 May 2021 14:11:02 GMT) Full text and rfc822 format available.

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

From: "Trent W. Buck" <trentbuck <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 15504 <at> debbugs.gnu.org
Subject: Re: bug#15504: 24.3; find-dired's numerous prompts are inflexible
 and annoying
Date: Mon, 31 May 2021 00:09:57 +1000
Michael Heerdegen wrote:
> "Trent W. Buck" <trentbuck <at> gmail.com> writes:
> 
> > I'm fine with the "no bug here, closing".
> > Below is some context / brainstorming / waffling, for the record.
> > [...]
> 
> For repeated calls with slightly different parameters I rather use
> `repeat-complex-command' instead of the command itself.
> 
> Apart from that detail: would it make sense to provide a more general
> command that allows to view the output of any shell command to be viewed
> as a dired buffer, or something like that, to get rid of the
> restrictions?  Or what would you suggest instead?

I don't have a cler vision of what I want, but yeah, that's my vague thinking.
Which is pretty much

    (dired-mode default-directory (cdr find-ls-option))

so I'm not sure why I had all those other lines in the original post.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 28 Jun 2021 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 301 days ago.

Previous Next


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