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

[Mark Lodato <lodatom@gmail.com>]

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.

> 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