From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7831 invoked from network); 25 Nov 2020 17:24:46 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 25 Nov 2020 17:24:46 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khyWB-00C9gk-VX; Wed, 25 Nov 2020 11:23:48 -0600 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1khyWA-00DMY6-Qk; Wed, 25 Nov 2020 11:23:46 -0600 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khyW7-00DMWN-6G for ding@lists.math.uh.edu; Wed, 25 Nov 2020 11:23:43 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1khyVW-0011z3-Ep for ding@lists.math.uh.edu; Wed, 25 Nov 2020 11:23:42 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gvlzC801Q0D4xVlka4FBvNmCTdzNDAljQ1Z1HIMMpv8=; b=DxXOW95gmVAGqHaMW9F8xNZJ7A r1Zy7+u2HjJZx7eSQuklGpsJ2fVd4wYGzZDH8/ZlzxgZwWKQrPtdl0QiGPwhdDJzcyMXua/5R3QY0 ulDdvje8Xl4Ay5oSVs87e65YEw9WEECFECAGHooCSsQUSx8PkehMWJ98D/MhETPfOg60=; Received: from ericabrahamsen.net ([52.70.2.18] helo=mail.ericabrahamsen.net) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khyVL-0000ro-BE for ding@gnus.org; Wed, 25 Nov 2020 18:23:01 +0100 Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 1ABD2FA02E; Wed, 25 Nov 2020 17:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1606324973; bh=gvlzC801Q0D4xVlka4FBvNmCTdzNDAljQ1Z1HIMMpv8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Iz7wk27ASUe8MuYpRVlj/GOZFAwuz53wfHGJWmlD6AcoYwQ3T3Cb/mSYVrOoyYx0F dI+ChNTtf5a6jR5rpitV/WX4yfhd5mmx/X21dgXJ2c50Jh42FeDONSWjO8lcqqnlHM YoG+1MsUtD+gSDkmMNsoVafqtcAPiUAAgUXK7XcQ= From: Eric Abrahamsen To: Eric S Fraga Cc: ding@gnus.org Subject: Re: gnus-search: do not limit search to specific groups? References: <87r1ohdadc.fsf@ucl.ac.uk> <87wny9664r.fsf@tullinup.koldfront.dk> <87mtz5bljx.fsf@ucl.ac.uk> <87o8jl5xbd.fsf@tullinup.koldfront.dk> <87v9dta3i8.fsf@ucl.ac.uk> Date: Wed, 25 Nov 2020 09:22:51 -0800 In-Reply-To: <87v9dta3i8.fsf@ucl.ac.uk> (Eric S. Fraga's message of "Wed, 25 Nov 2020 14:57:03 +0000") Message-ID: <87mtz5tkpg.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: Precedence: bulk Eric S Fraga writes: > On Wednesday, 25 Nov 2020 at 15:24, Adam Sj=C3=B8gren wrote: >> All my nnml-groups are without server name.=20 > > Interesting. I had definitely been under the impression that a server > name would not be necessary for nnml groups (what does it really mean in > that context anyway?) so glad to get confirmation. > >> But maybe it's only mixing that confuses Gnus?! > > Well, the error output from gnus-search is: > > ,---- > | nnselect-run: gnus-search-run-query on > | ((search-query-spec (query . test gnus search with nnml) (raw)) > | (search-group-spec > | (nnml: nnml:mail.pandian)=20 > | (nnml:outlook nnml+outlook:mail.aaa > | nnml+outlook:mail.bbb > | nnml+outlook:mail.pandian))) > |=20 > | gave error (error No search engine defined for nnml:) > `---- > > (I've reformatted for ease of reading and elided some groups etc.) > > So it looks like I have to define the search engine for nnml: (without > server). Maybe that would fix this mixed server case. I think the behavior here will depend on how you've defined your search engine. If you've done it in gnus-secondary-select-methods, like: '(nnml "outlook" (gnus-search-engine notmuch)) Then that will work for "nnml+outlook", but not bare "nnml". If you've defined it for all nnml servers, like: (add-to-list 'gnus-search-default-engines '(nnml . notmuch)) It will apply to all nnml backends. But then I guess you'd have to define your remove-prefix globally, as well. In general, the purpose of the string label (like "outlook") is to differentiate one installation from another: you might have another set of nnml files somewhere else, with a separate search index, and that's how Gnus will tell them apart. Another way of searching "all" your messages is to go to the *Server* buffer and search a whole server with "G". In your *Server* buffer, did you used to see separate servers for "nnml" and "nnml+outlook"? I'm surprised that nnir let you search all messages without restricting to a group or set of groups. As far as I know the code for selecting the scope of the search hasn't changed. > Although the problem is currently solved for me by having deleted the > server-less group, it would be nice for gnus-search to have returned the > results for the second group-spec above, maybe with a warning that not > all groups were searched? I'm talking to Andy now about how best to do this: I have a local patch that allows individual search failures without bodging the whole process, but the demoted error warnings currently don't make it through to where the user can see them. This is also connected to the fact that if ephemeral group creation leads to an error, the group isn't cleaned up correctly. Hopefully we can get all these things fixed at once, soon. Thanks, Eric