Thread (4 messages) flat view 4 messages, 3 authors, 2021-05-18

Re: Man pages have colors? A deep dive into groff

From: Junio C Hamano <hidden>
Date: 2021-05-18 01:27:10

Felipe Contreras [off-list ref] writes:
Junio C Hamano wrote:
quoted
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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.



Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help