[arch-projects] [MKINITCPIO][PATCH 1/2] Fix colors display in some options

[Sébastien Luttringer]

On Tue, Feb 5, 2013 at 2:01 AM, Dave Reisner <d at falconindy.com> wrote:
> On Tue, Feb 05, 2013 at 01:44:28AM +0100, Sébastien Luttringer wrote:
>> Colors initialization was called after arg parsing. This disallow error messages
>> and options called directly from arg parser to use colors.
>> By example, call `mkinitcpio -k toto' or `mkinitcpio -L'.
>
> -k isn't immediately processed, btw. This isn't a valid example. It's
> potentially true only of -g, -H, -L, and -P.
>
>>
>> This patch initialize colors when terminal is able to support it but disable it
>> if users don't wants it (with -n).
>>
>> Signed-off-by: Sébastien Luttringer <seblu at seblu.net>
>> ---
>
> I'm starting to have second thoughts about this patch. It means that you
> could potentially have color or not based on the order of the flags
> passed. That is...
>
>   $ mkinitcpio -L -n # this will be in color
>   $ mkinitcpio -n -L # this will not be in color
>
> I tend to think missing out on color for a small number of options
> versus this inconsistent behavior isn't worthwhile. I could look into
> some refactoring so that the 4 options I mention above are colorized
> properly, after arg parsing is done. It's probably equally wrong to be
> doing work straight out of arg parsing.
I agree. Re-factoring is a better solution!

-- 
Sébastien "Seblu" Luttringer
https://www.seblu.net
GPG: 0x2072D77A