GNU bug report logs - #50179
[PATCH] Add support for "bright" ANSI colors to ansi-color and term-mode

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Tue, 24 Aug 2021 04:04:02 UTC

Severity: wishlist

Tags: patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50179 <at> debbugs.gnu.org
Subject: bug#50179: [WIP PATCH v3] Add support for "bright" ANSI colors to ansi-color and term-mode
Date: Wed, 22 Sep 2021 12:39:55 -0700
[Message part 1 (text/plain, inline)]
On 9/19/2021 7:45 AM, Lars Ingebrigtsen wrote:
> It seems like term.el was reworked in
> 
> commit ae4969c2d69a74c896eb49c9a34aeb645ffed082
> Author:     Julien Danjou <julien <at> danjou.info>
> AuthorDate: Thu Jun 28 12:40:24 2012 +0200
> 
> to use faces instead of colour names, but ansi-color wasn't.  Looking at
> the code in both ansi-color and term, I think it would indeed make sense
> to rework ansi-color to use faces, too, and inheriting like you suggest
> makes sense to me.  (We generally prefer using faces instead of colour
> names these days.)

Since no one chimed in opposing this change, here's a WIP patch that 
adds faces to ansi-color. This removes the use for `ansi-color-map', 
since `ansi-color-get-face-1' does all the work now. I benchmarked this 
a bit and the performance seems on par with the old implementation, 
except when we fontify *more* stuff thanks to the support for additional 
ANSI escapes; in that case, it takes longer, scaling linearly with the 
amount that gets fontified.

I also took the opportunity to redefine a couple of the faces. For 
example, ANSI SGR 7 (negative image) was defined to use the `error' 
face. Given that `:inverse-video' exists, that seems pretty suboptimal.

I don't quite know what to do about man.el though. It has overrides for 
a few of the faces used by ansi-color. I could maintain that behavior 
fairly easily, but maybe it makes sense to have it use the defaults from 
ansi-color. More generally, I wonder what we should do to accommodate 
users of ansi-color who want to apply non-default faces for a specific 
case. I guess they could redefine `ansi-color-basic-faces-vector' and 
friends? That's basically how man.el used to work, and it wouldn't be 
hard to continue supporting that if we wanted.
[0001-Add-support-for-bright-ANSI-colors-in-ansi-color.patch (text/plain, attachment)]
[0002-Add-support-for-bright-ANSI-colors-in-term-mode.patch (text/plain, attachment)]

This bug report was last modified 3 years and 242 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.