Re: [RFC] Gnus generalized search, part II

[Eric Abrahamsen]

Andrew Cohen <address@hidden> writes:

> Dear Eric:
>
> This is great (although I haven't tested it yet:))
>
> Some questions/comments:
>
> The previous version of nnir that I contributed could search multiple
> backends (indeed something I did routinely with messages threads that
> were spread out across gmane and my personal email which in turn was a
> combination of imap and namazu) but it was cumbersome since it worked
> only with queries that were understood simultaneously by both
> backends. This effectively reduced the searches to rather simple ones,
> but it was nevertheless pretty effective. One aspect of the design that
> was important was that C-g while searching wouldn't abort the whole
> thing but just the current backend. So if the gmane search web site
> wasn't responding, for example, a C-g would move things along and still
> search the other backends. Can you make sure that your modifications do
> the same? (They probably do, but I just want to make sure:))

Interesting, I hadn't thought of that. Right now `nnir-run-query' looks
more or less like it did, the only difference with the indexed searches
is that instead of `call-process' they run `start-process' and
`accept-process-output'. It's possible that will react differently to
quitting, I'll try it and make sure it still behaves the same.

If I can get threading working, things may change again: I don't know
how threads interact with C-g.

> I occasionally do some complicated searching which needs access to the
> raw imap syntax (and indeed the imap thread referral uses the ability of
> nnir-run-query to accept a raw imap search constructed in
> 'nnimap-make-thread-query) so I think it is important for nnir-run-query
> to accept this format as well. I know I previously said it would be good
> if the whole criteria thing goes away, but perhaps I was too
> hasty. Right now a prefix arg to the gnus entry point to searching sets
> the criteria in a complicated fashion; we could simplify this so that a
> prefix arg skips all parsing of the query-spec and sends the raw query
> directly to the query engine (as is the case now if you use a criterion
> of 'imap). The user would presumably not try this with multiple backends
> since the syntax wouldn't be common.

Yes, I was thinking something similar -- users ought to be able to drop
to raw strings if they need to. That shouldn't be hard to implement at
all.

(That said, I think the query parsing can handle anything IMAP can
handle -- I'd like to know if it can't!)

> My limited window to work on this is rapidly closing. The good news is
> that I think that all of the nnselect stuff is done (aside from some
> renaming of things) and seems to be working. The bad news is that after
> weeks of trying I still have no git access :( I have sent 2 emails to
> this list, and on the advice of several people I have signed up for a
> savannah account and requested membership in emacs, but its been almost
> a week with no response.
>
> The changes are pretty large and somewhat invasive, and since there are
> likely to be bugs found in testing I expect some back and forth with
> testers and subsequent modifications in the code. I doubt I have the
> wherewithal to do this without using git. So if I can't get access soon
> I may have to forgo pushing these changes.

That would be unfortunate. Here's hoping that gets sorted soon.

Eric