Re: [PATCH 1/5] Allow explicit ANSI codes for colors

From: Mark Lodato <lodatom@gmail.com>
Date: Feb 27, 2010, 18:24 UTC
Message-ID: <ca433831002271024t5af1dba9m6ca719c114e54892@mail.gmail.com>
In-Reply-To: <20100227085144.GD27191@coredump.intra.peff.net>

On Sat, Feb 27, 2010 at 3:51 AM, Jeff King <peff@peff.net> wrote:

> I am not against this patch if it gets us some flexibility that is not
> otherwise easy to attain,

Besides disallowing multiple attributes (e.g. bold blink), the current parser does not have a way to specify colors for 16-color mode colors 8-15, 256-color mode colors 0-7, or any 88-color mode colors. There are also other esoteric attributes [1] that some user might want to use, such as italic or franktur. I don't know if anyone will ever use this feature, but it wasn't hard to implement.

> but wouldn't it be more user friendly for us
> to support "red blink bold ul italic"?

Yes, I think this should be done whether or not the patch in question is accepted.

Show 5 quoted lines

> AFAICT, the only things standing
> the way of that are:
>
>  - we don't support the italic attribute yet (are there are a lot of
>    others that we are missing?)

Wikipedia [1] lists a whole bunch of codes, including italic, but I doubt anyone uses them. My thought was if someone really wanted to use one of these obscure codes, they could do it with the patch in question. I don't think it's worth allowing users to type "italic".

>  - the parser in color_parse_mem already understands how to parse
>    multiple attributes, but it just complains after the first one

It seems like this restriction should be lifted. However, if this is done, then COLOR_MAXLEN should be increased to 32 or so, and there must be explicit checks to make sure the buffer does not overflow. Technically, VT500 terminals accept up to 16 parameters up to 5 digits each [2], which would be 98 bytes, but this is overkill.

[1] http://en.wikipedia.org/wiki/ANSI_escape_code [2] http://vt100.net/emu/dec_ansi_parser#ACPAR