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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8505 invoked from network); 25 Oct 2021 16:37:43 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 25 Oct 2021 16:37:43 -0000 Received: from localhost ([::1]:35900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mf2yj-0007C2-7I for ml@inbox.vuxu.org; Mon, 25 Oct 2021 12:37:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34968) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mf2yf-0007Bt-03 for info-gnus-english@gnu.org; Mon, 25 Oct 2021 12:37:37 -0400 Received: from ciao.gmane.io ([116.202.254.214]:34846) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mf2yd-0001fN-66 for info-gnus-english@gnu.org; Mon, 25 Oct 2021 12:37:36 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mf2yb-0008EZ-E2 for info-gnus-english@gnu.org; Mon, 25 Oct 2021 18:37:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: info-gnus-english@gnu.org From: Eric Abrahamsen Subject: Re: gnus-search & imap: always "CHARSET UTF-8" when literal+ is supported Date: Mon, 25 Oct 2021 09:37:26 -0700 Message-ID: <87a6ix5ad5.fsf@ericabrahamsen.net> References: <87fsstx875.fsf@ericabrahamsen.net> 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:2DPNr7ZqWImTj1+Me+E/4WnSxHA= Received-SPF: pass client-ip=116.202.254.214; envelope-from=gegu-info-gnus-english@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: "info-gnus-english" David Edmondson writes: > On Friday, 2021-10-22 at 10:47:42 -07, Eric Abrahamsen wrote: > >> David Edmondson writes: >> >>> Using current emacs git head, talking to outlook.office365.com over >>> IMAP. >>> >>> Attempts to use gnus-search always fail with the server reporting: >>> >>> (("NO" ("BADCHARSET" "(US-ASCII)") "The" "specified" "charset" "is" "not" "supported.")) >>> >>> Looking at gnus-search.el, `gnus-search-imap-search-command' always >>> sends CHARSET UTF-8 if the server supports literal+ (which this one >>> does). Sending US-ASCII (or no charset at all) causes the server to >>> return the required results in simple test cases. >>> >>> Is there a way to determine whether a server supports UTF-8 in searches, >>> and adjust the command sent accordingly? If not, could the use of UTF-8 >>> be controlled with (yet another!) variable? >> >> A bit of internet research seems to indicate that Exchange can't handle >> UTF-8 encoded search strings, and also there's no way to test that in >> advance apart from simply seeing if it errors. Awesome! > > That's also the impression I gained. > >> I think what this means is that it's impossible to search for non-ascii >> text on an Exchange server (can that be true?!). If that's true, then >> the imap search command should be using the presence of a multibyte >> string as the test for whether to use CHARSET UTF-8 or not. You're not >> going to be able to search for a multibyte string, anyway. >> >> Would you try eval'ling the below, and tell me if it works okay when >> searching for a string with no non-ascii characters in it? > > This works in a few simple tests, yes. Thanks! Great, I'll put this change in. >> Also, when you do get the error message above, how does that present to >> the user? Did you have to go digging to find it? > > I had to dig. The observed behaviour is that no messages match the > search. I'm hoping to make some changes to Gnus error reporting that should make this less difficult. The user should definitely see the difference between "no results" and an actual error. Thanks for the report.