tech-userlevel archive

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

Re: Support for boolean queries in apropos

On Sun, Mar 11, 2012 at 4:32 PM, Matthew Mondor
<> wrote:
> On Sun, 11 Mar 2012 14:56:48 +0530
> Abhinav Upadhyay <> wrote:
>> 1. Either remove the keywords AND, OR, NOT from the list of stopwords
>> and treat them as Boolean operators. That means if the user specifies
>> any of these keywords in the query, they will be treated as Boolean
>> operators and the results will be evaluated that way. This has the
>> side-effect that if the user unknowingly uses these keywords in his
>> query when he did not really intend to use them as Boolean operators,
>> he might be surprised at the results.
> If this was used, probably that a form of escaping could be used when
> we want to match AND, i.e. 'AND'?  Another option would be to preserve
> the verbose names but to require a prefix for the symbols of boolean
> operators, such as :AND which would be less likely to clash.
>> 2. Or, another option is to use '||', '&&' and '~' as the symbols for
>> the OR, AND, NOT Boolean operators respectively in the apropos
>> frontend and pre-process it to build a proper SQL query so that Sqlite
>> is able to understand and execute it properly.
> This makes a lot of sense, as I doubt that many would need to do man
> page searches for these strings, the operators are short to type and
> they're used as a convention by many languages.  I think that I would
> prefer option 2, personally.

Yes, I too like this more.

> && c && d ...).  However, it seems that currently a default && matching
> is used (match pages containing all words).  Perhaps that a command
> line switch could be used to specify that the default behavior should
> be || (match all pages containing at least one of the words) too?  This
> would make the (a || b || c || d) case cleaner...

Right, the default behaviour is &&. The reason for sticking with this
default behaviour is that, the results are usually better this way but
it makes sense to provide an option to switch this behaviour.


Home | Main Index | Thread Index | Old Index