It's fine if it's just an extension; I'm working on a SRFI 166 implementation as part of Schemepunk[1] right now, and I'm going to include the bright colors either way. It seems like a broadly useful feature. And `as-true-color` is not a substitute: the bright colors would use the colors of the user's terminal theme, just like the bold variants of the 8 basic ANSI colors.

[1]: https://github.com/ar-nelson/schemepunk

Hi Adam,

I had added `as-true-color`, is this sufficient?

I'm trying to avoid adding new features at this late stage,

although we could consider any number of extensions,

from the notably lacking background color settings, up to

my unpublished sixel library.

[I'm tempted to add the background colors anyway.]

--

Alex

On Sat, Jun 20, 2020 at 5:07 AM Adam Nelson <xxxxxx@nels.onl> wrote:

Could SRFI 166 be updated to include the 8 bright ANSI colors? I'm
referring to SGR parameters 90-97, which are the same color as the bold
versions of colors 30-37. Presumably these would be named
`as-bright-red`, `as-bright-blue`, etc.

In some terminals, these are distinct from bold colors. (as-bright-red
x) would render in the same color as (as-bold (as-red x)), but without a
bold font. On platforms that do not support this distinction (Windows)
the bright colors could just be aliases for the bold colors.