From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 15F0E1F597;
	Wed, 18 Jul 2018 10:22:34 +0000 (UTC)
Date: Wed, 18 Jul 2018 10:22:33 +0000
From: Eric Wong <e@80x24.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: meta@public-inbox.org
Subject: Re: [PATCH 3/3] SearchIdx: Allow the amount of indexing be configured
Message-ID: <20180718102233.jt4loti4k3x3wkp7@whir>
References: <87a7qpjve8.fsf@xmission.com>
 <20180717233058.30820-3-ebiederm@xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20180717233058.30820-3-ebiederm@xmission.com>
List-Id: <meta.public-inbox.org>

"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> This adds a new inbox configuration option 'indexlevel' that can take
> the values 'positions', 'terms', and 'over'.

The names of these user-facing configuration variables aren't
obviously "levels" at all; especially to people not familiar
with Xapian or public-inbox internals.

As for "over", at least it should be spelled out "overview";
but really, I would much prefer something which wouldn't require
consulting the manual for explanations, such as:

	'full', 'medium', 'minimal'

Where it's obvious which one sits relative to the others.

That wouldn't tie our user-facing configuration to our internal
choices or terminology used by Xapian, either.  I'm pretty happy
with Xapian; but it may be worth exploring other search engines
at some point...

> --- a/lib/PublicInbox/SearchIdx.pm
> +++ b/lib/PublicInbox/SearchIdx.pm
> @@ -47,6 +47,7 @@ sub git_unquote ($) {
>  
>  sub new {
>  	my ($class, $ibx, $creat, $part) = @_;
> +	my $levels = qr/(positions|terms|over)/;

Please anchor matches so they match expected strings exactly.
It lets typos be caught and makes life easier for 3rd-party
tools and implementations if we're stricter in what we accept.
Captures aren't necessary, so '?:' can be used:

	qr/\A(?:full|medium|minimal)\z/

Same comment applies to patch 2/3