From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout.scc.kit.edu (scc-mailout.scc.kit.edu [129.13.185.201]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p9CMrbVq009995 for ; Wed, 12 Oct 2011 18:53:39 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-01.scc.kit.edu with esmtp (Exim 4.72 #1) id 1RE7g7-0003Vi-5d; Thu, 13 Oct 2011 00:53:35 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1RE7g7-0004mx-4e; Thu, 13 Oct 2011 00:53:35 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1RE7g7-0000DW-3c; Thu, 13 Oct 2011 00:53:35 +0200 Received: from schwarze by usta.de with local (Exim 4.72) (envelope-from ) id 1RE7g7-0000LL-2r; Thu, 13 Oct 2011 00:53:35 +0200 Date: Thu, 13 Oct 2011 00:53:35 +0200 From: Ingo Schwarze To: Kristaps Dzonsons Cc: tech@mdocml.bsd.lv, Jason McIntyre Subject: Re: apropos "types" (WAS apropos(1) option naming) Message-ID: <20111012225335.GE28987@iris.usta.de> References: <20111008142925.GB28339@iris.usta.de> <4E90689C.6000206@bsd.lv> <20111008210136.GA8119@iris.usta.de> <4E9601D5.2080501@bsd.lv> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9601D5.2080501@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) 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