[Controversial Patch for Bug 18180] kfind sloppy match for simple search strings

Klas Kalass klas.kalass at gmx.de
Sun Jul 21 01:31:31 BST 2002


Am Saturday 20 July 2002 00:20 schrieb aleXXX:
> On Friday 19 July 2002 18:27, Kurt Granroth wrote:
> > On Thursday 18 July 2002 10:28 pm, Klas Kalass wrote:
> > > Example:
> > > kfind -> kfind.cpp is FOUND
>
> Maybe I wanted to search only for files named exactly "kfind" ?
> This would no longer be possible with this kind of matching.
You can still do kfin[d] if you really badly need to only see this one file 
(sorry I left out that example in my original mail ;).

>
> > > k?ind -> kfind.cpp is NOT FOUND
> > > k?ind* -> kfind.cpp is FOUND
> > > .c -> kfind.cpp is FOUND
> > > *.c -> kfind.cpp is NOT FOUND
> > >
> > > May I apply?
> >
> > This is an intriquing idea.. but it's not at all obvious behavior.  I
> > wonder if it would be better if the results were somehow split into two
> > sets.. absolute matches and "kinda" matches.
>
> IMHO it ain't to much to expect that users know the meaning of "*" and "?".
Well, IMO it is. Even locate handles searchstrings the way I propose as I 
found out yesterday!
Just do some usability tests with users who were never exposed to Linux and/or 
command lines before and see how they will do if you ask them to find the 
file with a name containing "kfind". 

I think that we cannot expect from everybody to know about wildcards, but we 
can expect from people who need that exact match to know about kfin[d] (or at 
least know about the what's'this where we could add that example).

> And I don't think this "fuzzy" search is yet another checkbox in kfind
> worth.
Agreed, nobody wants that.

Anybody supporting my patch?

Klas




More information about the kde-core-devel mailing list