<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body>
Andreas Franke wrote:
<blockquote cite="mid200402110318.i1B3IRs6025063@monster.ags.uni-sb.de"
type="cite">
<blockquote type="cite">
<pre wrap="">product:Browser
</pre>
</blockquote>
<pre wrap=""><!---->
Quicksearch does this.
</pre>
</blockquote>
Ah, sorry, didn't realize that (probably because the help page doesn't
mention it).<br>
<br>
<blockquote cite="mid200402110318.i1B3IRs6025063@monster.ags.uni-sb.de"
type="cite">
<blockquote type="cite">
<pre wrap="">product:Browser/Foo,Bar,Baz
</pre>
</blockquote>
</blockquote>
...<br>
<blockquote cite="mid200402110318.i1B3IRs6025063@monster.ags.uni-sb.de"
type="cite">
<pre wrap="">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. "/".
</pre>
</blockquote>
Except that using a colon to separate the product from the components
overloads its meaning as a field/value separator.<br>
<br>
<blockquote cite="mid200402110318.i1B3IRs6025063@monster.ags.uni-sb.de"
type="cite">
<blockquote type="cite">
<pre wrap="">status:RESOLVED,VERIFIED
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<br>
<blockquote cite="mid200402110318.i1B3IRs6025063@monster.ags.uni-sb.de"
type="cite">
<pre wrap="">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
syntax.
</pre>
</blockquote>
Ideally we'd get both at once, and it shouldn't be so hard to do. We
just need Search.pm to scan the content field for prefixes and convert
them to their corresponding criteria.<br>
<br>
-myk<br>
<br>
</body>
</html>