[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15504: 24.3; find-dired's numerous prompts are inflexible and annoyi
From: |
Trent W. Buck |
Subject: |
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.