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 17877 invoked from network); 4 Jun 2021 19:27:42 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 4 Jun 2021 19:27:42 -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 1lpFTp-00D3bB-2h for ml@inbox.vuxu.org; Fri, 04 Jun 2021 14:27:41 -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 1lpFTo-000mEq-Fh for ml@inbox.vuxu.org; Fri, 04 Jun 2021 14:27:40 -0500 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 1lpFTn-000mEk-Ex for ding@lists.math.uh.edu; Fri, 04 Jun 2021 14:27:39 -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) (envelope-from ) id 1lpFTj-00Bb0V-4c for ding@lists.math.uh.edu; Fri, 04 Jun 2021 14:27:39 -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=EuY6Rcvp+rDWt6/pH0zvGhA4l+dQdjeoZmCtr/QIDPw=; b=YcTbE4FDFa0fh4bENqAwxgvFkQ UBShn6ZVhWrk8n0WwRby+81tF+EwzX5Jo6mh4Lujh7+YF7sZsyAwWt3jQncqgZj1TUK5V4idTrJEe m4DfnWxlpuysedeoSNYSflGCuEGDZV02917m7sb/mTy6cZ6cvHiWtzC53C1+G7Gg9ccI=; 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 1lpFTb-0000oH-2E for ding@gnus.org; Fri, 04 Jun 2021 21:27:30 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lpFTa-0000Pj-0f for ding@gnus.org; Fri, 04 Jun 2021 21:27:26 +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: Fri, 04 Jun 2021 12:27:02 -0700 Message-ID: <87h7ida0s9.fsf@ericabrahamsen.net> References: <87h7j22iqx.fsf@gnus.jao.io> <87czt2pzcr.fsf@ericabrahamsen.net> <875yyu4u0p.fsf@gnus.jao.io> <874keed4fi.fsf@ericabrahamsen.net> <87wnrabpg0.fsf@ericabrahamsen.net> <871r9i32qb.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:BQhVxlK/PWe10VmbKMiKmP9Epgc= List-ID: Precedence: bulk "Jose A. Ortega Ruiz" writes: > so i don't know why it happens, but the problem seems to be in the > gnus-search-run-search method for imap servers. specifically, this > snippet translating the query spec to a query string: > > (setq q-string > (gnus-search-make-query-string engine query)) > > > - when i run the query mark:! with point at a subtopic, this code in that > method sets q-string to "FLAGGED", and things work. > - when i run the query mark:! with point at Gnus, the code above sets > q-string to "KEYWORD flag" (and, naturally, no results are found). > > the reason for that is that, in the first case, query is > > ((parsed-query (mark . flag)) (query . mark:!) (raw)) > > while, in the second case, it is > > ((parsed-query (keyword . flag)) (query . mark:!) (raw)) > > so it seems that the reader of the query, or its translator to a sexp > down the line, is sensitive to where in the Groups buffer point is. This is melting my brain. I can't reproduce this, and don't see how it's even possible. It seems to be the query parsing process that's going wrong, but that happens before the code even looks at which groups are being searched, and parsing simply happens to a string: it doesn't vary depending on the servers being searched, much less on where point is when you start the search. Neither does there seem to be any code that could transform "mark" -> 'keyword! I might need to ask you to up your debugging skills... :)