* bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying
@ 2013-10-02 1:45 Trent W. Buck
2013-10-04 4:16 ` Kevin Rodgers
0 siblings, 1 reply; 6+ messages in thread
From: Trent W. Buck @ 2013-10-02 1:45 UTC (permalink / raw)
To: 15504
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 {} +".
\f
(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")))))))
\f
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''
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying
2013-10-02 1:45 bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying Trent W. Buck
@ 2013-10-04 4:16 ` Kevin Rodgers
2021-05-30 5:55 ` Lars Ingebrigtsen
2021-05-30 11:41 ` Trent W. Buck
0 siblings, 2 replies; 6+ messages in thread
From: Kevin Rodgers @ 2013-10-04 4:16 UTC (permalink / raw)
To: 15504
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying
2013-10-04 4:16 ` Kevin Rodgers
@ 2021-05-30 5:55 ` Lars Ingebrigtsen
2021-05-30 11:41 ` Trent W. Buck
1 sibling, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-30 5:55 UTC (permalink / raw)
To: Kevin Rodgers; +Cc: 15504
Kevin Rodgers <kevin.d.rodgers@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying
2013-10-04 4:16 ` Kevin Rodgers
2021-05-30 5:55 ` Lars Ingebrigtsen
@ 2021-05-30 11:41 ` Trent W. Buck
2021-05-30 12:30 ` Michael Heerdegen
1 sibling, 1 reply; 6+ messages in thread
From: Trent W. Buck @ 2021-05-30 11:41 UTC (permalink / raw)
To: 15504
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying
2021-05-30 11:41 ` Trent W. Buck
@ 2021-05-30 12:30 ` Michael Heerdegen
2021-05-30 14:09 ` Trent W. Buck
0 siblings, 1 reply; 6+ messages in thread
From: Michael Heerdegen @ 2021-05-30 12:30 UTC (permalink / raw)
To: Trent W. Buck; +Cc: 15504
"Trent W. Buck" <trentbuck@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying
2021-05-30 12:30 ` Michael Heerdegen
@ 2021-05-30 14:09 ` Trent W. Buck
0 siblings, 0 replies; 6+ messages in thread
From: Trent W. Buck @ 2021-05-30 14:09 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 15504
Michael Heerdegen wrote:
> "Trent W. Buck" <trentbuck@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-05-30 14:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-02 1:45 bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoying Trent W. Buck
2013-10-04 4:16 ` Kevin Rodgers
2021-05-30 5:55 ` Lars Ingebrigtsen
2021-05-30 11:41 ` Trent W. Buck
2021-05-30 12:30 ` Michael Heerdegen
2021-05-30 14:09 ` Trent W. Buck
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).