From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p98FDfer026948 for ; Sat, 8 Oct 2011 11:13:42 -0400 (EDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 35E05104015; Sat, 8 Oct 2011 17:13:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 47Xv4yfnyWJy; Sat, 8 Oct 2011 17:13:34 +0200 (CEST) X-KTH-Auth: kristaps [83.250.3.9] X-KTH-mail-from: kristaps@bsd.lv Received: from macky.local (c83-250-3-9.bredband.comhem.se [83.250.3.9]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 95FCE10400C; Sat, 8 Oct 2011 17:13:33 +0200 (CEST) Message-ID: <4E90689C.6000206@bsd.lv> Date: Sat, 08 Oct 2011 17:13:32 +0200 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv CC: Jason McIntyre Subject: apropos "types" (WAS apropos(1) option naming) References: <20111008142925.GB28339@iris.usta.de> In-Reply-To: <20111008142925.GB28339@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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