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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3605 invoked from network); 23 Mar 2022 16:38:10 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 23 Mar 2022 16:38:10 -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.2) (envelope-from ) id 1nX3zt-006Ahz-35 for ml@inbox.vuxu.org; Wed, 23 Mar 2022 11:38:09 -0500 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94.2) (envelope-from ) id 1nX3zs-006EPD-G3 for ml@inbox.vuxu.org; Wed, 23 Mar 2022 11:38:08 -0500 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1nX3zr-006EP6-7A for ding@lists.math.uh.edu; Wed, 23 Mar 2022 11:38:07 -0500 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.2) (envelope-from ) id 1nX3zp-00BJVD-Bg for ding@lists.math.uh.edu; Wed, 23 Mar 2022 11:38:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:References:Message-ID:Date:Subject: From:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4hGHX5UCfzBkp3zbNmMDf22cFgEvh/NuFaYZ+yrNGOU=; b=o5WfwOXlWoguHlRCTDHpFTaetP 2qvJYTVX0NgWVG8Z+o1jQqN3qjBhiQq+o7vfMX5kNJ58RgXZzwl7i6ijS2W+K6Iu1ohvhjM+P5fYZ +gI5A3xvcdAv7QfgZ7HJMQxjnLOwVq8okAypQdpcvEXm0q6gWnlWgWdoYyL1FXoJpnJY=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nX3zi-00063p-98 for ding@gnus.org; Wed, 23 Mar 2022 17:38:01 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nX3zh-0002Go-7K for ding@gnus.org; Wed, 23 Mar 2022 17:37:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: gnus-search configuration example for notmuch Date: Wed, 23 Mar 2022 09:37:50 -0700 Message-ID: <87h77oiq01.fsf@ericabrahamsen.net> References: <87pmmfl20w.fsf@free.fr> <874k3qlw39.fsf@ericabrahamsen.net> <87a6di2yim.fsf@free.fr> <87o81yja43.fsf@ericabrahamsen.net> <87wnglu48g.fsf@uwo.ca> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cancel-Lock: sha1:j2kwT6YczUt8eSA5Jyh5Gi2NUnU= List-ID: Precedence: bulk Dan Christensen writes: > On Mar 22, 2022, Eric Abrahamsen wrote: > >> To add to what everyone else has said: most of the mail backends (nnml, >> nnmaildir, etc) keep their messages as files on the file system, so any >> search engine that indexes files and gives you full filenames back as >> search results (including notmuch, namazu, mairix) will work with them. >> It's really nnimap that is a special case, as you're not supposed to >> know or care where/how it stores its messages, and instead use the >> client/server interface. > > I guess nnfolder is also a special case? My mail is currently split > between nnfolder and nnimap (using dovecot), and my current search > engine is mairix, which can provide its results as a folder full of > files each containing a single message. Right now I use nnmairix to > view my search results, but it is a bit buggy and doesn't have some > features than gnus-search and nnselect seem to have, so I wouldn't > mind switching. But since I'm pretty familiar with the mairix search > syntax, I'd like to keep using mairix. Is this not possible? I don't think nnfolder is a special case: as long as both the Gnus backend and the search engine deal in absolute file paths, they should be able to talk to one another. If something special needs to be done to translate mairix search results into something that nnfolder can understand, I'd like to know about that and implement it. You can certainly continue to use mairix. nnmairix creates its own search groups and populates them; mairix with gnus-search just returns a list of file paths. If you like using mairix's search syntax, but want to use the gnus-search syntax for nnimap, you can first set: (setq gnus-search-use-parsed-queries t) To parse queries by default, then use _unparsed_ queries for mairix through one of a few approaches: 1. (setq gnus-search-mairix-raw-queries-p t): all queries against a mairix search engine will be unparsed. 2. Add (raw-queries-p t) to the config for one specific mairix search engine 3. Give a C-u prefix to the "G G" search command, for one single search Note that any of these options mean you won't be able to issue a single search against multiple groups belonging to nnfolder and nnimap at the same time; you'll have to use separate searches. HTH, Eric