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

[Kristaps Dzonsons <kristaps@bsd.lv>]

Hi Ingo,

I'm tagging out a release right now; in the coming one, we can focus 
much more on getting the options Just Right.

> Except that maybe, i still hope for something like
>
>    apropos -s 3 -Q Xr open and Er ENOENT
>    apropos -s 4 -Q An Gray or An Reyk

I'd like to spend some time on this.  I'll speak aloud because I'm still 
undecided.  Let's consider just the matchings in your statements above 
(e.g., An Gray) and assume logical operators exist.  (The rest is for a 
different thread.)

The current state of option matching is by symbolic type: "func foo" to 
query all functions named "foo".  Functions, in this case, are defined 
by `Fo' and `Fn'.  These definitions are encoded when the database is 
created; the source macro type is lost.

I could change the database to instead encode only the mdoc macro name, 
as in your example.  Then "Fo foo AND Fn foo" would match the above. 
The problem with this so far is that it's not user friendly at all.  It 
assumes users know about mdoc, and in general they don't.  Furthermore, 
it doesn't work for -man, because now we need to do things like `SH foo 
AND Sh foo' for sections.  This gets ugly.  And then what happens for 
the -man description, or name?  It has no macro at all.  Making people 
search for `Nd text' and having it also search -man, which has no `Nd', 
is confusing because sometimes there'd be a macro, sometimes not.

But that's ok, actually.  Because we could let apropos have some 
symbolic types, like "function", that would magically expand into "Fo 
foo AND Fn foo", hiding the types from the users.  Something like 
"section" would expand into "Sh foo AND SH foo".  And "desc" into `Nd' 
for -mdoc and the free-form description for -man.

But then... for something like the description, we would have a symbolic 
name but not a macro name.  This is confusing.

Overall I'm still on the fence as to the best approach.  On the one hand 
we have lots of flexibility, but significant complexity.  On the other 
hand, we have a tighter database, but our choices for types may appear 
arbitrary.

I slightly prefer, however, the best approach of biting the pillow and 
trying to determine the best symbolic types, which will be encoded 
directly in the database as they are now.  If we do a good job, we can 
probably match the flexibility of `Xr open' without the complexity (not 
even to mention that many macros aren't semantically interesting).  But 
I'm open to suggestions, so please chime in!

Take care,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv