On 9/19/2021 7:45 AM, Lars Ingebrigtsen wrote: > It seems like term.el was reworked in > > commit ae4969c2d69a74c896eb49c9a34aeb645ffed082 > Author: Julien Danjou > 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.