* 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.