[pacman-dev] Bring in official color support at last?

[Vojtěch Gondžala]

Dne 5.1.2011 17:54, Dan McGee napsal(a):
> 2011/1/5 Vojtěch Gondžala<vojtech.gondzala at gmail.com>:
>> Dne 5.1.2011 17:01, Sven-Hendrik Haase napsal(a):
>>>
>>> Hey,
>>>
>>> I'm not vogo but I know he's been trying to get his work upstream since
>>> 3 years and was rejected last time in order to wait for pacman 3.1. We
>>> passed that long ago and I think pacman-color should be given another
>>> chance to go upstream.
>>> The AUR package with the patch is here:
>>> http://aur.archlinux.org/packages.php?ID=11827
>>>
>>> It is a rather popular package so it might make a fine addition.
>>>
>>> -- Sven-Hendrik
>>>
>>
>> Hi,
>>
>> I'm not sure that the patch is ideal for upstream, it's need little bit
>> refactor. I'm too busy to do it now, but next release is far. I can do some
>> changes at the weekend, if other developers want accept this patch.
>
> Oooh, nothing like a hot-button topic to bring traffic to the ML. :)
>
> Thoughts:
> 1. Vogo- no rush, it's obviously been baking a while, no need to pull
> it out of the oven early so take your time.
> 2. I think we'd (the core and regular pacman devs) support this if all
> done right.
> 3. We need to ensure this doesn't interfere with i18n concerns,
> especially non-latin alphabets. I have no idea about the current
> state, but generate the zh_CN.utf8 locale on your box and try running
> this patch under that as a quick test.
> 4. git now does color, in C code, in a pretty platform-agnostic way.
> They've even managed to add a emulation layer for Windows. I don't
> think we need all of that, but using their code as a resource is
> probably a smart idea. See color.h, color.c, and compat/winansi.c in
> their codebase.
> 5. Does this handle redirects to non-terminals OK; is the
> configuration simple but effective, etc.
> 6. Do we have people willing to review large patches like this? Allan,
> Nagy, Xavier and I get very bogged down when we are the only people
> looking over code changes and lose interest because we don't get to
> enjoy writing our own code.
> 7. Do we have people willing to help Vogo make changes to this patch
> once it is submitted and reviewed?
> 8. A patchset rather than a patch is easier to review, and moving some
> of this stuff to a color.c/color.h would be helpful (and move the
> color definitions to color.h so you don't need the extern junk).
>
> -Dan


Hi all,

there is my  first idea how colorize output of pacman. It's simple and 
function. It's using an ansi escape sequencies, I looked for solution in 
a GNU coreutils (ls, grep...) and it's same. Diffred solution is used in 
utility tput but is needed ncurses and ncurses isn't good dependency for 
pacman, in my opinion.

This patch doesn't support configuration of used colors, but it adding 
'nocolor' option in pacman.conf and '--nocolor' argument, for disable 
colorize output. I tested patch on some locale and works good with all.

Any idea how do it beter?


-- 
Vojtěch "vogo" Gondžala
-------------- next part --------------
A non-text attachment was scrubbed...
Name: color.diff
Type: text/x-patch
Size: 33419 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/pacman-dev/attachments/20110109/ec967f42/attachment-0001.bin>