Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >> > This looks much better. >> > >> > I wonder a good follow-up (hint, hint! :) would be to have >> > exec_man_man() and exec_man_cmd() in builtin/help.c set this depending >> > on color.ui (so we'd do it by default with "auto"). >> > >> > Then e.g. "git help git" would look prettier than "man git". >> >> As long as color.man.ui can be used to override the blanket >> color.ui, I think it is a good idea. > > Why not use color.pager? I dug a bit to refresh my memory and it turns out that the reason we should not do so is because it means something totally different. color.[ch] defines want_color() that applications like "diff" and "log" can use to see if the application is configured to paint its output in colors. When that layer says for that particular application it should be decided automatically, then we call into color.c::check_auto_color() which is the only user of pager_use_color (which is set from the color.pager configuration variable). The purpose of that call is to ask if the pager is capable of colors. So in short, the color.pager is about "is the pager capable of colors?" and the color.ui (and color.<cmd>) is about "does the user wants output from <cmd> in color?" We need to use color.help or something that controls whether the user wants help/man in colors, and perhaps default it to "auto" like color.ui defaults to, which then in turn would consult "color.pager". Tying it directly to "color.pager" is wrong.
