emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Isearch in dired


From: Chong Yidong
Subject: Re: Isearch in dired
Date: Tue, 11 Nov 2008 17:55:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Juri Linkov <address@hidden> writes:

>>  (1) There is a significant probability that the user might want to
>>      match the non-file parts.  For instance, the user may want to find
>>      all files modified on a certain date.
>
> Using isearch to find files with a certain date is not the easiest way
> to accomplish this task, especially when the date format is not ISO.
> There are better tools like M-( dired-mark-sexp and find-dired
> with -mtime and -mmin options.  However, isearching dates and other parts
> of a dired buffer will still be possible even with context-dependent
> isearch - when point initially is not a file name.

On the contrary, it is the most intuitive way to search Dired buffers,
for anyone who is used to using C-s for buffer navigation.  It's also
faster, in many cases, than doing M-(.  Having this operation fail
unexpectedly in Dired would be unfortunate.

(Also, gnu ls gives the date in ISO format by default, so that
particular objection is a red herring.)

> The false matches also include owner and group names, month names in
> non-ISO formats, and sometimes even file permissions.

Owner and group names, maybe, but I don't think we have to worry about
people being getting false search matches for files named `rw-r--r' etc.


As for doing a filename search based on the current column, that is a
tad more reasonable, but still suffers from the "unexplained behavior"
problem.  There is simply no visual clue for the user that the "dwim
behavior" is taking place, or what rules govern it, so it will seem like
Emacs is behaving erratically.  Note, also, that upon entering the Dired
buffer, point is placed in the filename column by default, so if the
user attempts to search for dates with C-s, the search fails by default!

So I don't think the dwim behavior should be the default (I support
providing it as an option, though).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]