From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#55477: 29.0.50; flymake-goto-next-eror shows terminal like color codes in mini buffer Date: Wed, 18 May 2022 13:11:46 -0700 Organization: UCLA Computer Science Department Message-ID: <0d94334a-0ae2-d4b0-f448-e05196ef8951@cs.ucla.edu> References: <87a6bg5wrt.fsf@codeisgreat.org> <87wnekktos.fsf@gnus.org> <87v8u43xq1.fsf@codeisgreat.org> <87sfp8krgy.fsf@gnus.org> <878rr0dolv.fsf@codeisgreat.org> <874k1ojakj.fsf@gnus.org> <875ym3ikht.fsf@codeisgreat.org> <87leuzdqxz.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4835"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Cc: Alan Mackenzie , 55477@debbugs.gnu.org, Pankaj Jangid To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 18 22:12:27 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 1nrQ1z-000164-1a for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 May 2022 22:12:27 +0200 Original-Received: from localhost ([::1]:54470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nrQ1w-0007lb-KL for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 May 2022 16:12:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nrQ1a-0007lP-2B for bug-gnu-emacs@gnu.org; Wed, 18 May 2022 16:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39803) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nrQ1Z-0005s8-PN for bug-gnu-emacs@gnu.org; Wed, 18 May 2022 16:12:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nrQ1Z-0003FD-IN for bug-gnu-emacs@gnu.org; Wed, 18 May 2022 16:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 May 2022 20:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55477 X-GNU-PR-Package: emacs Original-Received: via spool by 55477-submit@debbugs.gnu.org id=B55477.165290471712460 (code B ref 55477); Wed, 18 May 2022 20:12:01 +0000 Original-Received: (at 55477) by debbugs.gnu.org; 18 May 2022 20:11:57 +0000 Original-Received: from localhost ([127.0.0.1]:33700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nrQ1U-0003Eu-Lh for submit@debbugs.gnu.org; Wed, 18 May 2022 16:11:56 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nrQ1S-0003Eg-G4 for 55477@debbugs.gnu.org; Wed, 18 May 2022 16:11:55 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DCE6C1600B0; Wed, 18 May 2022 13:11:47 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XPvHGR94pGYa; Wed, 18 May 2022 13:11:47 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1BBFC1600BE; Wed, 18 May 2022 13:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EmIwCq5gTTKu; Wed, 18 May 2022 13:11:47 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E53E71600B0; Wed, 18 May 2022 13:11:46 -0700 (PDT) Content-Language: en-US In-Reply-To: <87leuzdqxz.fsf@gnus.org> 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:232601 Archived-At: On 5/18/22 04:24, Lars Ingebrigtsen wrote: >> The above expression is returning "curve"; in all three environments, >> >> en_US.UTF-8 >> en_IN.UTF-8 >> en_IN > That seems like a bug, because in the final environment, Emacs doesn't > seem to be able to display the curved quote. But Emacs *can* display curved quotes in that environment. It's=20 misdisplaying them as individual bytes, and that's the bug: it should=20 simply display the characters as-is. This bug is not limited to quotes. Put this into a file t.el: (defun =CE=B4-replace-string (from-string to-string) (declare (interactive-only "use `search-forward' and `replace-match' instead.")) (interactive)) (defun test-fun (obj) (if (stringp obj) (=CE=B4-replace-string "from" "to"))) run "LC_ALL=3Den_IN emacs -Q", visit the file, evaluate the first form,=20 and then do M-x flymake-mode followed by repeated uses of M-x=20 flymake-goto-next-error. It will eventually report the diagnostic: =E2=80=98=C3=8E=C2=B4-replace-string=E2=80=99 is for interactive use only= ; use =E2=80=98search-forward=E2=80=99=20 and =E2=80=98replace-match=E2=80=99 instead. That is, the "=CE=B4" (which in UTF-8 is #xCE #xB4) is misinterpreted as = the=20 two Latin-1 characters =C3=8E (#xCE) and =C2=B4 (#xB4). I suspect that the problem is due to Alan's recent change to the meaning=20 of EQ. As I understand it, when byte-compiling, EQ doesn't mean the same=20 thing that it does ordinarily. But format-message (which is used by the=20 byte compiler) uses EQ to decide what to do, and it bases its decision=20 on whether the resulting string is unibyte or multibyte. Evidently this=20 new meaning of EQ is messing up format-message's internals. I'll CC this to Alan to see whether he can provide some insight.