Re: Support for boolean queries in apropos

[Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>]

On Sun, Mar 11, 2012 at 4:32 PM, Matthew Mondor
<mm_lists%pulsar-zone.net@localhost> wrote:
> On Sun, 11 Mar 2012 14:56:48 +0530
> Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost> 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.

Thanks
Abhinav