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: make-thread with lambda form instead of function symbol Date: Mon, 17 Apr 2017 10:32:29 -0700 Message-ID: <87pogbkki9.fsf@ericabrahamsen.net> References: <87efws9w3c.fsf@ericabrahamsen.net> <87bmrvu9am.fsf@ericabrahamsen.net> <87y3uzjz91.fsf@hanan> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492450430 1495 195.159.176.226 (17 Apr 2017 17:33:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Apr 2017 17:33:50 +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 Mon Apr 17 19:33:44 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 1d0AX0-0000D1-Et for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2017 19:33:42 +0200 Original-Received: from localhost ([::1]:38028 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0AX4-0002ML-UD for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2017 13:33:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0AWO-0002ME-EU for emacs-devel@gnu.org; Mon, 17 Apr 2017 13:33:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0AWL-0006KL-9J for emacs-devel@gnu.org; Mon, 17 Apr 2017 13:33:04 -0400 Original-Received: from [195.159.176.226] (port=59870 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d0AWL-0006KC-2s for emacs-devel@gnu.org; Mon, 17 Apr 2017 13:33:01 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d0AWC-0007Yp-0E for emacs-devel@gnu.org; Mon, 17 Apr 2017 19:32:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:5sdINHIUj9dwGiX7KFp9KpLzyjo= 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:214084 Archived-At: Andrew Cohen writes: > It would be great to get the searches done concurrently. This is the > last serious (IMHO) problem with gnus searches---the searching part can > take a long time. The current implementation tries to collect everything > to minimize connections to the backends (i.e. searching multiple groups > on a single backend should use a single connection) but even imap > searching gets to be a pain when several imap servers are involved. Subjectively, the thread trick seems to really speed things up. I've also been looking at some of the IMAP extensions to improve single-server search -- MULTISEARCH could speed things up significantly, and wouldn't be hard to implement. I'm not sure about SEARCHRES. It doesn't look like it actually saves much time, and would be very hard to integrate with the structure of Gnus searches. > Just a side comment: the existing nnir-run-query handles multiple groups > with different backends mostly just fine (albeit searching sequentially > rather than concurrently). The limitation is that the search query must > be common to the different backends (this is the big issue that your > general search query language would fix). I (used to) routinely combine > gmane, namazu, and imap groups in my searches (used to since I stopped > using namazu long ago and gmane search is now defunct :(). > > And a side-side comment: if the different backends allow different > criteria then search groups from different backends will prompt for > different criteria for each backend. Cumbersome but occasionally > helpful. Actually, in the implementation I'm working on now, I've removed the additional criteria. The general query language makes selecting imap keys unnecessary, the gmane "author" criteria can simply be transformed from the "from" keyword (not to mention that this support is now theoretical!), and all the other backend criteria specify groups: can't we just take that from the group search spec? I'll be happy to re-instate criteria if they really turn out to be necessary, but I'd like to try to do away with them if possible. Eric