brian m. carlson wrote: > On 2021-05-19 at 09:26:12, Ævar Arnfjörð Bjarmason wrote: > > > > On Tue, May 18 2021, brian m. carlson wrote: > > > > > Would you consider various projects coloring their respective manual > > > pages differently to be a desirable state of affairs? > > > > I think it's an important distinction that we're not coloring any manual > > pages, it's a question of whether we invoke "man" invoked by "git help > > <whatever>" with the exact same paramaters/options a user would get with > > "man git-<whatever>". > > Yes. I would expect that if the man option is chosen, then we invoke > man without modification. Do you also expect git to call diff without options? > The documentation says, "use the man program as usual". "As usual" > implies the way the user would invoke it. The documentation can be updated. > > I don't think it's confusing in that context if we learn to do some "man > > with fancy on top" in this mode. > It's pretty obvious that "git help commit" and "cargo help build" both > are intended to invoke man when used in the normal way. And I don't. I expect the output `foo help $x` to be decided by foo. If I do `python help len` and I get an error, that's fine. > > But if colors only add, but don't substract information by default > > that's not an issue for the color blind, correct? Or at least that's > > been my understanding in helping color blind user in the past (and not > > being color blind myself). > > The problem becomes if the color is indistinguishable from other > elements. It is not indistiguishable; a blind person would be able to distinguish them. As much as they can without the patch. > It is _also_ a problem if we have two colors with sufficient contrast > between the foreground and background but those colors look the same and > there is no other distinguishing factor. There is another distinguising factor: they are *bold*, or _underlined_. > So, yes, if the colors only add information and they can otherwise be > distinguished, then it's fine. We are setting *bold*, _underlined_, and REVERSE. Exactly in the same way as they are set already. A truly colorblind person would see no difference at all. > What I don't like is when a program colors text in a certain way, I > can't read it, and then I can't read the help output or documentation to > turn it off. If you can't read `man git`, that has absolutely nothing to do with this patch. > I am specifically arguing against coloring our documentation We already already coloring our documentation. > and help output because it leaves users with little recourse to fix > the problem. man git. -- Felipe Contreras
