From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Gnus generalized search, part II Date: Fri, 21 Apr 2017 22:27:45 -0700 Message-ID: <87mvb92er2.fsf@ericabrahamsen.net> References: <87zif930mt.fsf@ericabrahamsen.net> <87tw5hjnzr.fsf@hanan> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492838948 6267 195.159.176.226 (22 Apr 2017 05:29:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Apr 2017 05:29:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 22 07:29:04 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d1nbT-0001RN-DJ for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2017 07:29:03 +0200 Original-Received: from localhost ([::1]:34256 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1nbW-0002NE-4k for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2017 01:29:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1nao-0002MD-Jp for emacs-devel@gnu.org; Sat, 22 Apr 2017 01:28:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1nak-0004V4-Ch for emacs-devel@gnu.org; Sat, 22 Apr 2017 01:28:21 -0400 Original-Received: from [195.159.176.226] (port=60142 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d1nak-0004SU-69 for emacs-devel@gnu.org; Sat, 22 Apr 2017 01:28:18 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d1naZ-0000UP-UY for emacs-devel@gnu.org; Sat, 22 Apr 2017 07:28:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 67 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:YzgtRu9nzK1I60DOnL3lZyCORlA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214205 Archived-At: Andrew Cohen 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