Laying QuickSearch to rest

Myk Melez myk at
Wed Feb 11 18:31:35 UTC 2004

Andreas Franke wrote:

>Quicksearch does this.
Ah, sorry, didn't realize that (probably because the help page doesn't 
mention it).


>This could be added to quicksearch, but you have to admit
>that it's a special case to combine product and component
>info in a single item.  And you can see that the line 
>between "arcane" and "intuitive" syntax is quite thin, 
>in this case it's " :" vs. "/".
Except that using a colon to separate the product from the components 
overloads its meaning as a field/value separator.

>Ok, this is indeed a bug in quicksearch (though noone
>ever got around to file it).  What quicksearch offers is
>to start your query with RESOLVED,VERIFIED. 
>If would be indeed a good thing if this were recognized 
>anywhere in the query, with and without the status: prefix.
We should simplify this by requiring the status: prefix.  One of the 
reasons the current syntax is arcane is that there are multiple ways of 
specifying criteria that most searches don't use, complicating the 
learning process while optimizing unnecessarily.  Rarely used functions 
don't need such extreme shortcuts, even if a small minority of users 
benefit from them, especially if they prevent the larger pool of 
potential power users from learning and using the feature set.

>The alternative path suggested in this discussion seems
>to be to first replace the javascript tool with the
>full text search perl tool, and then extend that with
>the perl-equivalent of quicksearch in a more intuitive
Ideally we'd get both at once, and it shouldn't be so hard to do.  We 
just need to scan the content field for prefixes and convert 
them to their corresponding criteria.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the developers mailing list