Re: overhaul apropos(1) interface

[Kristaps Dzonsons <kristaps@bsd.lv>]

On 13/11/2011 00:54, Ingo Schwarze wrote:
> Hi,
>
> here is a new version of my overhaul after Kristaps' changes.
> The patch given below is not likely to apply cleanly to anybody's
> repo, it requires the apropos_db.* rename first.  It is meant
> for quick review; if you agree with the direction, i'll figure
> out how to get this in cleanly.
>
> So, here is what the overhaul does:
>
>   * Remove -I from the main program.
>     Logically, that's not a global option,
>     but a per-expression thingy.
>   * Sort the arguments of exprcomp.
>     All the world uses (argc, argv),
>     why should we suddenly go for (argv, argc)?
>   * I agree with dropping MATCH_EXACT:
>     That's rarely needed and can easily be constructed
>     as MATCH_REGEX with ^...$.
>   * For the same reason, let's drop case-sensitive MATCH_STR:
>     It's rarely needed and can easily be constructed with MATCH_REGEX.
>   * Keeping MATCH_STR seems OK: It is needed as the default
>     when the type is unspecified.
>   * The MATCH_REGEXCASE enum item is unused already now,
>     since the iflag is compiled into the regex object.
>     So drop that one as well.
>   * Only two enum items remain; that's better and more easily
>     expressed by a single boolean integer (expr.regex).
>   * The exprexec() function requires a mask argument,
>     or all search keys will act as "any" (important bug fix
>     along the way!).
>
> The most massive changes are in exprcomp().
> I strongly dislike the proposed interface.
> It is cumbersome and requires too much typing.
> The -eq and -re arguments are exceedingly ugly, and the
> implementation is hard to get right - if i remember
> correctly, not all cases work properly right now.
>
> Thus, i have simplified my interface proposal to just this:
>
>    apropos [-s section] [-S arch] query_phrase [...]
>
>    query_phrase ::= [[macro[,...]](=|~)]query_value
>
> So, the value to be searched for can optionally
> be preceded by '=' (for string search) or '~' (for regex search),
> and that can optionally be preceded by one or more macro names,
> joined by commas.  Including "i" among the macros switches
> regex searches to case-insensitive and has no effect on
> string searches.

Ingo,

I'm working on the final parts of this check-in, so please hold off on 
this file!  It's by no means finished; as mentioned in the source 
checkin, I'll post to tech@ when the implementation is feature complete. 
  Consider, to gauge the complexity:

  apropos Ar == foo -a Ar =~ baz

(I don't care at all about the connecting syntax, ==, etc., so long as 
it's regular.  Your notation is not extensible to case-insensitive 
matching: can one extend to include these?)

Anyway, the "AND" is tricky: each file's evaluation state must be 
retained for all keyword entries (which have no guarantee on ordering) 
then post-operated.  Thus, I'm maintaining evaluation trees during the 
parse.  The goal is to make the trivial case -- "Ar foo", say -- as fast 
as in the simple implementation before.  (I guarantee the trivial case 
by the partial evaluation.)

Anyway, I anticipate a few days til I get the final checkins.  The code 
is not tricky in implementation (not much, anyway) and guarantees 
arbitrary expressions with well-defined compute time.

I'm also not at all married to the filenames, but let's hold off for a 
bit more as I get these chunks into place.  apropos_db.c is fine by me, 
for the record.

Thanks again,

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