Re: any partial or rudamentary documentation of new nnselect work somewhere?

[Harry Putnam <reader@newsguy.com>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Harry Putnam <reader@newsguy.com> writes:

[...]

>> I could search on exact code in perl groups for example ... and return
>> exact bits of code with careful use of perl regex.
>>
>> Later on I added more (perl) code that created a directory and filled
>> it with symlinks to the actual messages where my regex found hits. I
>> could then pull that directory into gnus as an ephemeral group or
>> nndoc inside gnus.
>>
>> All very clunky and probably duplicating functionality already in gnus
>> but in a primitive and homeboy way.  Also very slow.
>
> It does duplicate what's possible in Gnus (this could be done even with
> Gnus as it stands now), using an external indexing program like namazu
> or notmuch. The one big caveat would be that these programs almost
> certainly wouldn't index perl code correctly -- I haven't tried it, but
> I'd be very surprised if they did it right.

That was roughly my thinking at the time...(about indexing) I
considered trying to incorporate one or another of the indexing search
tools available.

But, first off, I didn't know how to do that... but might have fumbled
my way thru.

But, second and more important... indexing perl or other kinds of
code; I new would be a loser. And that was my primary objective at
the time.

Back then there was a tool called glimpse that was still under
development (although, barely) that does have a near regex capability
and is also an indexing tool... but once again the indexing doesn't do
well with code.

So, decided to put up with slowness of full-fledged perl regex
searching.  Decided indexing just didn't go with the kind of searchs I
was interested in.

You would know vastly more than I about the capabilities of any of the
search tools available now. But I believe you are right in thinking
they would not index code very well at all.

> The generalized search functionality that I'm working on (built on
> Andy's nnselect branch) would let you create all kinds of weird search
> engine behavior. In theory it wouldn't be hard at all to create a "grep"
> mixin class for the indexed search engines, that accepted an additional
> "grep:" key, and ran the grep over the results of the initial search.
> Ie, you could enter the search string:
>
> subject:"having a problem" grep:"my ($smith, $jones) = @a;" since:3m
>
> The subject: and since: keys would be passed to the underlying search
> engine (notmuch or mairix, etc), which would return a first round of
> results very quickly. The results are in the form of filenames, so the
> grep: key could then be used to do a second pass over those files. A
> best-of-both-worlds situation.
>
> That sounds pretty useful. Maybe there's no need for a mixin class at
> all; this could be a standard feature of the indexed search class. If
> grep wasn't available on the system, you'd just get a polite note to
> that effect.

> Actually, there's already a regexp syntax: surrounding text with forward
> slashes. Search engines that don't handle regexps could simply transform
> "body:/(.*)/" into "grep:(.*)"...
>
> Hmmm...

Yes, yes, and away you go... That two phase bit sounds really
useful.  I am really sorry to be of no help at all.

If you fellows have any low level scut work that needs doing, and I do
mean `low level'... that is, no coding required.

I realize that is a piss poor offer, and there probably is nothing
like that involved... but still ... just in case .. the offer stands.