Re: apropos "types" (WAS apropos(1) option naming)

[Ingo Schwarze <schwarze@usta.de>]

Hi Kristaps,

Kristaps Dzonsons wrote on Wed, Oct 12, 2011 at 11:08:37PM +0200:

> Ok, I'm going to put together a potential list of types for review.

The first time where it becomes relevant to fix the list is when we
enable apropos, because after that, people have to rebuild their mandoc
databases on production systems each time we change the database format.
Until then, adding to the list and reordering it is fine.
Of course, nothing is wrong with planning ahead, nothing at all.

> I anticipate the biggest "problem", user-interfacedly, will be that
> of discerning "Fo made in the SYNOPSIS" and "Fo referenced in the
> body".

Any pressing need?
To search for "Fo, but only in the SYNOPSIS", i'd search
for Nm in the first place.

Are there any other cases where limiting searches to certain
sections might be useful?  I'm not sure.

> On 08/10/2011 23:01, Ingo Schwarze wrote:

>>   apropos An=Gray An=Reyk
>>   apropos Xr=open \& Er=ENOENT
>>   apropos 'Xr=open & Er=ENOENT'

> Why don't we just be a little more awesome and allow
> 
>  apropos '( An Gray && Xr open ) || ...'.

Three comments:

 1. I'd hate the follwoing two to be semantically different:
      apropos An Gray
      apropos 'An Gray'
    As the meaning of the first is
      apropos Nm=An Nd=An Nm=Gray Nd=Gray
    i fear we probably need the '=' token.
    I'd gladly be convinced otherwise, though.

 2. Obviously, string operations are not bitwise operations, so i see
    no point in doubling the operators, & and | should be fine.
    There is no need for |, but we should probably allow it as
    an optional, ignored token, just for symmetry.

 3. I expect 90% of the searches will remain just
      apropos keyword 
    some will become
      apropos macro=keyword
    a few will involve one operator,
    and two operators and grouping will be very rare in practice.
    Still, as long as it doesn't complicate the syntax for
    simple searches, which it doesn't seem to, it's nice
    to support grouping as well.
    It is not urgent, though.

> Meaning, the AND/OR/NOT logical operators and a notion of grouping?
> It doesn't seem too hard: matching would still be pretty
> straightforward. In fact, once we start to do any Boolean logic, the
> distance between arbitrary expression (such as the above) and
> something like Linux's dumb "-a" is quite small.  Might as well go
> the distance.

Yaya, i agree with that.

At least we should start in such a way that the syntax we start
with allows going the full distance later.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv