From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thierry Volpiatto Newsgroups: gmane.emacs.bugs Subject: bug#54774: 28.1; ansi-color with no colors in Emacs-28 Date: Sat, 09 Apr 2022 07:25:09 +0000 Message-ID: <874k32zovr.fsf@posteo.net> References: <877d80pstl.fsf@posteo.net> <87tub37lqe.fsf@gnus.org> <5f2525c7-bfc3-cac7-7dda-a10b11c6592d@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39069"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 54774@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 09 09:41:35 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 1nd5iv-0009yv-Vs for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Apr 2022 09:41:34 +0200 Original-Received: from localhost ([::1]:45628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nd5iu-0003FU-LK for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Apr 2022 03:41:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43398) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nd5iQ-0003FD-Ti for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2022 03:41:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42749) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nd5iQ-0008CU-Kw for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2022 03:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nd5iQ-000582-I0 for bug-gnu-emacs@gnu.org; Sat, 09 Apr 2022 03:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thierry Volpiatto Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Apr 2022 07:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 54774-submit@debbugs.gnu.org id=B54774.164949000819633 (code B ref 54774); Sat, 09 Apr 2022 07:41:02 +0000 Original-Received: (at 54774) by debbugs.gnu.org; 9 Apr 2022 07:40:08 +0000 Original-Received: from localhost ([127.0.0.1]:36645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nd5hX-00056b-MP for submit@debbugs.gnu.org; Sat, 09 Apr 2022 03:40:08 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:45859) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nd5hV-000561-BV for 54774@debbugs.gnu.org; Sat, 09 Apr 2022 03:40:06 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 15DEA240107 for <54774@debbugs.gnu.org>; Sat, 9 Apr 2022 09:39:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1649489999; bh=dMxYowevYe3Y4WjnNbCZNdNMW6jC8mnE6WHgwuRwAUY=; h=From:To:Cc:Subject:Date:Autocrypt:From; b=O6uQRNd5ZaqXX7n5WMQl+HzzRNhQjvPgR50ILAT4Sviv7sjs6axAFIBT6NC88VEHS uMt3xcNp7AI1nd5BG1MJnnVOJMxPS0Y0S8G46FAk/dgOqFaVPsXnhteVltmKEm7Irh 70fz0wwmxurUuSqP144vVT61jCjuIstbdPtm3eemAQSAgxCeU7kHazlymm5kzcSBiS XCRDRtViT80jPTfCRwOuSZwbtqti7G2V34oNi8b3pAhTYomPtfM2IQjUiH3+j8mZqc xhksuZ4jFB+kuo2UjkYLUHwwEtxvDlvU3XSlxwjP4Ec2EBlEKDr1/PQGP+o0OlKqaO bJwoN+FfD39PQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Kb6TT42wdz9rxN; Sat, 9 Apr 2022 09:39:57 +0200 (CEST) In-reply-to: <5f2525c7-bfc3-cac7-7dda-a10b11c6592d@gmail.com> Autocrypt: addr=thievol@posteo.net; prefer-encrypt=mutual; keydata= mQGNBF8ylcIBDADG+hy+zR6L4/vbdDDZuSaMmSrU3A5QZJpeBCvxTr7MpzzruZbhLPW1K3R6N2MA edi8Y+C8o27FVRIjpdbaKMGu9je7JV/TbUQYo3SOwCK1vM4LUn4V6ZLzSYkuiEt4eyMoiDdyvN0p kcK6P9x9DCetcEVszXzQg+yzCVrQ2hXWDXWT4M18EC3wtO7RHPouMqGiwBFhBAYErCqFWFxQHkfb tG/4yGyJ58rglb65O3qijjMWvYwcWZun9/7qm8Z4/4mHopmo2zgU+OrptnLSZfkZGz3Y7Uf452xQ GVq0Fv75NPvQru7y+DYVhuVXXyAmGxt+vf4rIiixMBbhKEPjcxEPAa2LTzex2IsTZR+QVG9uDnqC WcgaOEQ58fzXNvNhtwwF/Rgio2XWAJVdmFWS59/k9W58CIUSNKBMZh2XeGdEmtHvDtCxW3z6FJha 36RzOM3fMNNiAGdFZJA84gcdloJR+sHCDTTPT3784fjr+V8An7sI581NGFzkRQqPvEQCZbUAEQEA AbQSdGhpZXZvbEBwb3N0ZW8ubmV0iQHUBBMBCgA+FiEEI9twfRN7r3nig/xwDsVtFB0W75MFAl8y lcICGwMFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQDsVtFB0W75MB3QwAlTsVzFmr +S/tMKwwwOibjhNPi/OZiUC2AYfaqfVAiIHDT3RbzDe03sAJoomJkJnYVjGzQZwibCMO2+ITkMPV 2wvrd4CbgS1KCVbrltwcuK/nxPCBaHytOCZUIInnhJo5PE/h03K 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:229601 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello Jim and thanks for clarifications. Jim Porter writes: > On 4/8/2022 6:23 AM, Lars Ingebrigtsen wrote: >> Thierry Volpiatto writes: >>=20 >>> it seems using ansi-color-apply in Emacs-28 is not working properly, >>> there is no colors. In Emacs-29 it is working properly (very nice) >>> without needing a workaround used previously in emacs-27 (code commente= d). >>> See code below to reproduce and Screenshots attached. >> I'm not sure I understand this bug report. Are you asking for the >> code >> in ansi-color in Emacs 29 to be backported to Emacs 28.2? > > I think the issue is that there were some changes in Emacs 28.1 (by > me, see commit ceb9da3b7125fbdf0da04a3b158ac1e792c87f4f) to add > support for ANSI "bright" colors. Yes this is this commit that cause problems, commenting the first cond clause of `ansi-color-get-face-1` allows having the same behavior as with Emacs-27 with replacement of 256 colors sequences: #+begin_src diff diff --git a/lisp/ansi-color.el b/lisp/ansi-color.el index b379e710940..e9a251545ba 100644 =2D-- a/lisp/ansi-color.el +++ b/lisp/ansi-color.el @@ -861,8 +861,8 @@ BRIGHT, if non-nil, requests \"bright\" ANSI colors, ev= en if ANSI-CODE is a normal-intensity color." (when (and bright (<=3D 30 ansi-code 49)) (setq ansi-code (+ ansi-code 60))) =2D (cond ((<=3D 0 ansi-code 7) =2D (aref ansi-color-basic-faces-vector ansi-code)) + (cond ;; ((<=3D 0 ansi-code 7) + ;; (aref ansi-color-basic-faces-vector ansi-code)) ((<=3D 30 ansi-code 38) (list :foreground (face-foreground #+end_src I made a bug report on github to clarify what's wrong, see https://github.com/thierryvolpiatto/emacs-config/issues/1. > In 29, Miha added support for 256-color and 24-bit ANSI colors as well > (see 0fa2279b90bf5a638d8377032b71135e1374e8fb). Working fine without the need of replacing 256 sequences. > I've verified that Emacs 28.1 properly handles normal and bright ANSI > colors in shell output. Bold/italic/etc works correctly as well, even > though I added an unnecessary quote to the face definitions - that's > been fixed in Emacs 29, and could be backported to 28, though I don't > think it causes any serious problems. > > That said, it looks like Thierry had written some code for Emacs 27 > that scans the output of a command that uses ANSI 256-color sequences > and then translates those sequences into ANSI 8-color sequences that > ansi-color.el will understand. However, that code no longer works in > Emacs 28, possibly due to my changes to support ANSI bright > colors. I'm not sure this is actually a bug in Emacs; it may just mean > that Thierry's workaround needs to be updated to account for the > ansi-color.el changes I made. Apart advicing `ansi-color-get-face-1` I couldn't find how to fix my code as your changes are binding ansi-code 5 to `ansi-color-slow-blink` face which create unwanted squares. > I'm a little unclear about what actually broke though, and haven't had > a chance to dig deeper. Some basic testing of `ansi-color-apply' shows > that it does what I expect. From "emacs -Q": > > (require 'ansi-color) > (ansi-color-apply "\033[44mfoo\033[0m") > -> #("foo" 0 3 (font-lock-face (:background "blue2"))) > (ansi-color-apply "\033[44;33mfoo\033[0m") > -> #("foo" 0 3 (font-lock-face ((:foreground "yellow3") > (:background "blue2")))) > > That's the same behavior as Emacs 27.2 with some trivial differences > (Emacs 27.2 uses `foreground-color' instead of `:foreground'). You can have a try at my code which is here: https://github.com/thierryvolpiatto/emacs-config/blob/main/tv-utils.el#L1097 with and without advicing `ansi-color-get-face-1`: https://github.com/thierryvolpiatto/emacs-config/blob/main/init.el#L24 Thanks. =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmJROEgTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk2gXDACQDKzAwPKRlfbCVDGULmfkEaV2qHcY 4YBEypZxN/ymoCs5ou+8Ab2Oxq2ZRbubbORCgF4kVxWOsI1xN+J3HZ5iBn1BSmKR 6kUPlGM63MXFhaid7Tv+BTekh3yRIx9/Z+ZNVvb9K7InmpAfObvLeM2GYgIbFcMZ PbQX+c+Z8zaP4Pll6Pe2AAPKVrDgOvopLnebAoYr3HWCStDiqA1JFtknRIjPLdHt RuejO+KyhEkquilJmp8LKiXS5C3bUQRB/2s4PW17bUo7WpZAkp6zQWJhY4ui+EwR GZVKASlFB71GhDWncHM678aD+Fknm17ScL6nckpVEUI01z/0dHqfuEBXavZkOmdi VCw8p3xjKsBce0bkmWWm1A/YMg1jSekbliditcvqhoE4lUvLfQeJzErDembQow5I AKB8Gmp1zjh2Mb/fDZwkUqo30W/XEiGgIKG0qF1kh3MAMGh0RamYNxTt5smEx48B Ku+wN6MPYVZSLWrGODuzPdFSfOAQavyR5Fk= =Spwi -----END PGP SIGNATURE----- --=-=-=--