[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50179: [UPDATED PATCH] Add support for "bright" ANSI colors to ansi-
From: |
Lars Ingebrigtsen |
Subject: |
bug#50179: [UPDATED PATCH] Add support for "bright" ANSI colors to ansi-color and term-mode |
Date: |
Sun, 19 Sep 2021 16:45:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Jim Porter <jporterbugs@gmail.com> writes:
> There's one further enhancement that might make sense here: currently,
> color values are set via a vector of strings for `ansi-color', whereas
> they're set via faces for `term-mode'. Would it be better to use faces
> for `ansi-color' too? Perhaps they should even be the *same* faces; is
> there any reason an Emacs user (or package) would want ANSI colors to
> be different between `ansi-color' and `term-mode'? If so, maybe each
> `term-color-FOO' face should inherit from the (hypothetical)
> corresponding `ansi-color-FOO' face?
It seems like term.el was reworked in
commit ae4969c2d69a74c896eb49c9a34aeb645ffed082
Author: Julien Danjou <julien@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.) But:
> However, maybe there's a particular reason why `ansi-color' works this
> way that I'm not aware of. If the current way is best, that's fine by
> me too. Otherwise, just let me know and I can update the patches to
> include `ansi-color-FOO' faces.
I'm not really very familiar with ansi-color.el. Does anybody else have
an opinion here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no