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

[Trent W. Buck]

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.