From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#58168: string-lessp glitches and inconsistencies Date: Thu, 06 Oct 2022 17:34:42 +0300 Message-ID: <83mta9owal.fsf@gnu.org> References: <7824372D-8002-4639-8AEE-E80A6D5FEFC6@gmail.com> <877d1l55rn.fsf@gnus.org> <469814C2-197A-4BCA-8E2A-245577340C1E@gmail.com> <878rlzj1zv.fsf@gnus.org> <878rlzfylg.fsf@gnus.org> <017DAAA2-0383-4B47-855E-28348B2E9F06@gmail.com> <831qrnx1jc.fsf@gnu.org> <83k05fv9nv.fsf@gnu.org> <52286A5C-D947-4279-812E-173BB44046E1@gmail.com> <83v8oxp5lk.fsf@gnu.org> <4CFC3078-64FB-4EAC-A536-F6CBCEE2087D@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6423"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58168@debbugs.gnu.org, larsi@gnus.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 06 16:37:53 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ogS0X-0001Te-0Q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Oct 2022 16:37:53 +0200 Original-Received: from localhost ([::1]:42566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogS0V-00068u-Vg for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Oct 2022 10:37:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43848) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogRxn-0002yH-2S for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 10:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34027) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ogRxm-0007EM-Lj for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 10:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ogRxm-0007fB-9E for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 10:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Oct 2022 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58168 X-GNU-PR-Package: emacs Original-Received: via spool by 58168-submit@debbugs.gnu.org id=B58168.166506689329438 (code B ref 58168); Thu, 06 Oct 2022 14:35:02 +0000 Original-Received: (at 58168) by debbugs.gnu.org; 6 Oct 2022 14:34:53 +0000 Original-Received: from localhost ([127.0.0.1]:33105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogRxc-0007ef-UB for submit@debbugs.gnu.org; Thu, 06 Oct 2022 10:34:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogRxb-0007eJ-AT for 58168@debbugs.gnu.org; Thu, 06 Oct 2022 10:34:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49370) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogRxV-0007Bu-Oy; Thu, 06 Oct 2022 10:34:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=rDa2EtkkPGG8qQnZAH5rbc5cR0Dfl56/TXEjgiYimqU=; b=BeVH0ZcyD/YCKO1ZTvEl 0A6jTclWT/0IiurG3nFLxD4B3g74ku1XWP1RkHacdLkDiy9x+nslzlINaBhmwyypTkS9a2c6+RNsk B/0yyNuPV9JgR8nhWK+2Z7mTaXYiHHjGwwiksNXHCGbsRMTRrgGRtLcSdNxgv1/GGTp1AQgagZPGA xbuJDnHMhRdqXGq43m5NRVfaOESRk0HsunLRIRExF2OEvQA8DOAo7zcN7pvnnI8YiXhhWbDbzWJ+0 JcTH7OldQEDjvHVnf68Co3ZGg29stTj3xnCiKAv1KEDrkVTGvMIwXYoPvXwwUvgKlmalRHP9YxavO lRMFLZdSc5+WVQ==; Original-Received: from [87.69.77.57] (port=4297 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogRxV-0003QV-7n; Thu, 06 Oct 2022 10:34:45 -0400 In-Reply-To: <4CFC3078-64FB-4EAC-A536-F6CBCEE2087D@gmail.com> (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Thu, 6 Oct 2022 14:43:09 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:244674 Archived-At: > From: Mattias Engdegård > Date: Thu, 6 Oct 2022 14:43:09 +0200 > Cc: larsi@gnus.org, > 58168@debbugs.gnu.org > > 6 okt. 2022 kl. 13.13 skrev Eli Zaretskii : > > >> (format-message "%\345" 0) > >> => (error "Invalid format operation %å") > > > > And you want to show %\345 instead? > > Maybe, or (as the patch suggested) using a different wording for raw bytes. In any case %å is clearly a lie since that character wasn't in the format string. What would you rather see in such a case? I don't think it matters much, because whatever we produce we cannot be sure it will look identical to the original format string. > Oh, I see -- you are looking at the hunk that changed the labels, not the character tested. When 3fffc was changed into 3ffffc, the "expected" string needed to change accordingly; for the latter, it's \xfc or \374 depending on mode. > > > Why not test both #x3ffffc and #xfc? And the same question about > > \777777 vs \374. > > Testing #x3ffffc inserts the raw byte #xfc so that takes care of that -- the test already exercised inserting the unibyte raw byte #x80 and the patch didn't change that. We are talking about a test suite. A test suite doesn't have to assume that the internals work as they should, it should just test that. So testing both sounds to me better than testing just one assuming that this one covers both. > I don't think these two cases actually exercise different paths in redisplay since the buffer is multibyte: Again, this kind of considerations don't have a place in a test suite. What if tomorrow redisplay code will change to have two different paths? > \777774 is just octal for #x3fffc which was changed into the (intended) #x3ffffc, and \374 is octal for #xfc which is covered as above. Normally, yes. But this is a test suite...