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, 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.

This might be seem unfamiliar, but I like how Lisp supports sets such
as (AND a b c d ...) (OR a b c d ...) which seems cleaner than (a && b
&& 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...


Home | Main Index | Thread Index | Old Index