emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make-thread with lambda form instead of function symbol


From: Eric Abrahamsen
Subject: Re: make-thread with lambda form instead of function symbol
Date: Mon, 17 Apr 2017 10:32:29 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Andrew Cohen <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]