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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5728 invoked from network); 3 Jun 2021 21:28:17 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 3 Jun 2021 21:28:17 -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 1lousx-00CSSv-Rd for ml@inbox.vuxu.org; Thu, 03 Jun 2021 16:28:15 -0500 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 1lousx-000ZSA-83 for ml@inbox.vuxu.org; Thu, 03 Jun 2021 16:28:15 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lousv-000ZS4-VP for ding@lists.math.uh.edu; Thu, 03 Jun 2021 16:28:13 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1loust-00CSSb-Cr for ding@lists.math.uh.edu; Thu, 03 Jun 2021 16:28:13 -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=kRHnEHapxWufAqYLBtnFZcQp0N4DxlQXIo+j7qGUpJE=; b=YwxpSwhhZRRKAgI8wYtwJadXUX SHoq+9yYxuAm3v9Bnv7vQ+eKTmjTAGukDUkKAbxfDm4GFFrSJrhdw+w0NMBxiPttwaNgWrgmfOAZM dp4orXC/aOxlZ3mOTklgeiwAwGfkJZ4b01HVvTx5ToRbRZEsN1x/vsTWKbP9wKT4GWyM=; 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 1lousm-0006QE-Nh for ding@gnus.org; Thu, 03 Jun 2021 23:28:07 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lousi-0006ok-Kz for ding@gnus.org; Thu, 03 Jun 2021 23:28:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: Re: search for mark over Groups topic not working Date: Thu, 03 Jun 2021 14:27:45 -0700 Message-ID: <874keed4fi.fsf@ericabrahamsen.net> References: <87h7j22iqx.fsf@gnus.jao.io> <87czt2pzcr.fsf@ericabrahamsen.net> <875yyu4u0p.fsf@gnus.jao.io> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:68rs0MFO46dSHKoSYAoCsiDzBLo= List-ID: Precedence: bulk "Jose A. Ortega Ruiz" writes: > On Thu, Jun 03 2021, Eric Abrahamsen wrote: > >> "Jose A. Ortega Ruiz" writes: >> >>> Hi, >>> >>> I'm using the latest gnus-search in emacs master, with groups in nnimap >>> over several mailboxes and also notmuch folders, distributed among >>> several topics (all of them under [Gnus], no deeper nesting). Searching >>> for marks on those topics (e.g. mark:!), works fine. But when i go to >>> the [Gnus] parent topic and repeat the search, it always comes back >>> empty. I see traces of all subgroups being searched, but the nnselect >>> group comes back empty. Other searches (say, over the body of the >>> messages) work fine (i.e., if the search finds mails on topic [Foo] >>> under [Gnus], it also finds those same messages when the search is >>> performed on [Gnus]). >>> >>> Is anybody experiencing this problem? >> >> Sorry, I missed this when you first posted it. >> >> That's pretty weird! So to make sure I've got this right: the search >> only fails when you search the [Gnus] topic, > > right > >> and only when searching for marks? > > i cannot say categorically that it's /only/ for marks, but it definitely > happens with marks. i have an emacs compiled yesterday. > > the logs in message show no error for the groups containing marked > articles. only for the nndraft:drafts group: > > Search engine for nndraft: improperly configured: No search engine configured for nndraft: > > (as far as i can tell, nndraft is an "automatic" server, i haven't added > it explicitly in my config, so i'm no sure what's the proper way of > configuring its search engine.) > > and i also get one of those messages for the nnselect server (which i > guess it's a little bug, in that those groups cannot have a search > engine, can they?) > > Search engine for nnselect: improperly configured: No search engine configured for nnselect: > > my expectation is that those errors shouldn't affect the collection of > results, right? all the other groups are either nnimap or nntp (with > notmuch as the search engine). You're right, and I just realized that the code I put in place to handle this exact situation (if you're searching across multiple backends, search failure on one backend shouldn't prevent other backends from returning their results) is brain-dead: it's a condition-case, and even if we handle the error that doesn't mean that the code will continue executing. O for Common Lisp's restarts! Give me a little bit and I'll rework the code to do what it's supposed to do. Thanks for the report, Eric