On Tue, May 18 2021, brian m. carlson wrote: > [[PGP Signed Part:Undecided]] > On 2021-05-18 at 03:22:37, Felipe Contreras wrote: >> brian m. carlson wrote: >> > I think we should let the user decide whether they want to set this >> > feature themselves instead of setting it for them. For example, I have >> > specific colors set up with these environment variables, and I'd like >> > Git to honor them without having to configure Git independently of less. >> > I expect other users will expect Git's rendering of the manual pages to >> > work like other instances of man(1) on their system as well. >> >> It does respect them. >> >> This would render the man page with the color specified in the >> environment, not the default of git. >> >> LESS_TERMCAP_md=$'\e[1;33m' LESS_TERMCAP_me=$'\e[m' git help git > > It still doesn't work like other instances of man(1) on the system. > While you claimed that "that's a preference others don't share", I'm > pretty certain that I'm not the only person who feels this way. > > There's a big difference between Git coloring a Git UI, like a diff, and > Git coloring a separate program that already has sensible, standard > defaults. A user who has not configured any color settings would > probably not want Git to render manual pages one way, cargo to render > manual pages a second way, and still other programs to render manual > pages in other, incompatible ways. We need to consider not only the > impact that our decisions have in a vacuum, but what results similar > decisions from other projects would produce in the software ecosystem as > a whole. > > 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>". Right now our documentation seems to suggest that we won't do any such magic, but you can also set man.viewer to e.g. invoke a web browser or something instead of man(1). I don't think it's confusing in that context if we learn to do some "man with fancy on top" in this mode. >> > Additionally, using colors poses accessibility problems. I know someone >> > who, due to his colorblindness, finds terminal colors distracting and >> > hard to read, and prefers not to use them at all. >> >> git -c color.ui=never help git > > Yes, but unfortunately, since you've colored the manual pages, they may > be hard to read for the user who needs to read them to learn about your > configuration. This is great for you and me, who are already very > familiar with Git and know how to do that without looking, but not great > for the novice colorblind user. Is the objection here against the use of color, or that we e.g. replace grey bold underline with blue bold, as opposed to blue bold underline? I'm not running the patch in this thread currently, but I'm running with Felipe's earlier man alias noted in the other thread. So I see how losing the underline would be confusing. 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). I.e. issue isn't colors per-se, or even a UI that would make an egregious of coloring, rather it's if that UI uses color as a *replacement* for showing the same information in another way. I may be entirely wrong, but I think it's a point worth bringing up to find some solution here, i.e. if we find that not losing the underline (but adding color) is a solution acceptable to everyone. > For similar reasons, colorizing help output in general is unhelpful > because users cannot find the options to disable it. This seems to just be a re-hash of the old argument that git does coloring by default, not specifically about "git help <xyz>". I think there's good arguments for/against that, but I do think that ultimately it was a good choice, and programs such as hg(1) seemed to since have moved to git's more aggressive "color by default" stance. > In general, this is made worse because Git doesn't honor the unofficial > but widely supported NO_COLOR[0], so reading the documentation is > obligatory. I replied about NO_COLOR in <87lf8bqdv0.fsf@xxxxxxxxxxxxxxxxxxx>. Regardless of whether or not that's a good idea I don't see how it's relevant here. We'd support TERM=dumb, which is *the* standard way to tweak this for all programs. >> > Even users who want to use them might find some colors to be too >> > similar, and this patch doesn't permit them to be configured. >> >> Yes it does: >> >> LESS_TERMCAP_md=$'\e[01;38;5;33m' git help git > > I should clarify that the patch doesn't permit them to be configured > using the normal Git mechanisms. For example, unless the user sets the > environment variables, which take effect globally, they're stuck with > the colors that we've chosen here. Yes, they can specify a single > environment variable before the command, but practically nobody will do > that. > > It's my argument that the user doesn't want Git manual pages to be > colored differently than other manual pages on the system, but if you > believe differently, then we should allow the user to configure the > colors that are used in the Git-specific context using Git standard > mechanisms. I'm in vehement agreement about this. If we do invoke "man" differently based on how we'd do coloring for any other git program we invoke, we should of course be respecting the same configuration mechanisms. I.e. it should respect color.ui=auto etc., you shouldn't need to set LESS_TERMCAP_md or whatever. >> > In my particular case, despite having normal color vision, because I use >> > a transparent terminal which often results in a grey background, I find >> > the standard terminal red to be difficult to read, and so this patch >> > would result in a significant decrease in the readability of the manual >> > pages for me. >> >> If you have LESS_TERMCAP_md set in your environment, it won't. > > The problem is, I don't always. I am on call for a set of hundreds of > servers, only one of which has my shell configuration set up, so > defaults here matter. Moreover, because there are many novice users of > Git, we should consider that for a decent number of users, they > literally won't know where to look in our documentation to make > changes, and therefore the defaults matter for them, too. These servers don't have TERM in their list of AcceptEnv variables, or equivalent? In any case, I think for these defaults we need to be considering the vast majority of users, who are mostly interfacing with one or two computers in their use of "git", and who are running some modern OS that supports terminal coloring, which is why color.ui=auto became the default (to some objections at the time, but I think those have gotten less prominent as time marched on).
