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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Harry Putnam <reader@newsguy.com> writes:

> Andrew Cohen <cohen@bu.edu> writes:
>
> [...]
>
>> Sorry, I hadn't realized that you weren't using search previously. First
>> there are two "kinds" of searching---in a summary buffer you can search
>> (in a variety of ways, including the regex search you were trying); or
>> you can query servers to find articles matching certain search terms. In
>> this thread we are only talking about the latter search facility. It is
>> usually referred to as "nnir" searching. It is documented in the gnus
>> manual under "Searching" (go to info, select gnus, and select the
>> searching node). This should give you the information you need to start
>> searching (you might have to do some configuration depending on what
>> backends you are using).
>
> [...]
>
> Sorry, I should have explained the massive holes in my knowledge of gnus.
>
> Some yrs ago now, I wrote my own search engine in perl... I mean just
> a perl script that searched for regex thru thousands of gmane messages
> that I had downloaded with the agent.  So much downloading that I was
> kicked off gmane a few times... probably looked like something
> sinister.
>
> 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.

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...