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.devel Subject: Re: [ELPA] Add compat.el Date: Fri, 08 Oct 2021 08:56:14 +0300 Message-ID: <83czogys8x.fsf@gnu.org> References: <877dfavmzw.fsf@posteo.net> <87y278ieeh.fsf@posteo.net> <87y274mugn.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11114"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 08 07:57:08 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mYisV-0002dk-Rx for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 07:57:07 +0200 Original-Received: from localhost ([::1]:35226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYisU-00059H-1o for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 01:57:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYirx-0004UD-2F for emacs-devel@gnu.org; Fri, 08 Oct 2021 01:56:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58328) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYirv-00087r-Dv; Fri, 08 Oct 2021 01:56:31 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3390 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 1mYirv-0003QM-0b; Fri, 08 Oct 2021 01:56:31 -0400 In-Reply-To: <87y274mugn.fsf@posteo.net> (message from Philip Kaludercic on Thu, 07 Oct 2021 20:49:12 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276537 Archived-At: > From: Philip Kaludercic > Date: Thu, 07 Oct 2021 20:49:12 +0000 > > >From Emacs 27 onwards, this works as expected: > > (string-replace "\377" "x" "a\377b") > ;; => "axb" > > internally, the compatibility function for string-replace uses > replace-regexp-in-string. > > The same code, when evaluated by a version of Emacs older than 27 fails > to replace the character > > (string-replace "\377" "x" "a\377b") > ;; => "a\377b" Why did you expect that to work? What is the semantics of matching unibyte strings to multibyte strings? do you compare bytes or do you compare characters? There are no "100% correct" answers for these questions. > For string-search, using string-match internally, the "unusual" byte > cannot be found: > > (string-search (string-to-multibyte "\377") "ab\377c") > ;; => nil Because it isn't a byte, internally. > I couldn't find anything in NEWS.27 to indicate that something had > changed, so I wonder if there was a bug that was fixed? Does anyone > know or remember why this behaviour changed? This is a gray area of regexp matching, and it keeps constantly changing in Emacs under the hood. The changes are generally seen as "bugfixes" (though IMNSHO they aren't), and so they aren't called out in NEWS. And what would you say there about such subtle changes, anyway? So no one should expect it to work the same in different versions of Emacs.