{"thread":{"id":"58994","subject":"report default colors","startedAt":"2022-12-22T17:57:51Z","lastAt":"2022-12-23T01:32:32Z","messageCount":2,"participants":["James Lowden","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"469475","messageId":"FC7C600C-5D51-4BE0-82BD-9E28C88A1BB8@icloud.com","threadId":"58994","inReplyTo":null,"subject":"report default colors","fromName":"James Lowden","fromEmail":"james.k.lowden@icloud.com","sentAt":"2022-12-22T17:47:44Z","receivedAt":"2022-12-22T17:57:51Z","isPatch":false,"sender":{"key":"james.k.lowden@icloud.com","avatar":null},"body":"Hi, \n\nMy good friends, I would like a way to report all colors, default and configured, used by git.  \n\nI can report configured colors, \n\n$ git config --get-regexp color\ncolor.diff.meta black bold\ncolor.diff.frag magenta bold\ncolor.diff.old red bold\ncolor.diff.new blue bold\n\nwhich is not terribly useful, because those values came from a file I control.  \n\nI can get a list of all keys from \"git help\", which is something.  But I'm left guessing at which keys control the text on the screen for a given command, and what color they are.  \n\nIn the instant case, \"git push\" was rejected, and the reason is impossible to read because it's in yellow on a light blue background.  (Don't get me started on the pointlessly difficult antiquated arcane color control of ANSI terminals.)  My workaround is to guess what it probably says (probably it says I need to pull).  When that doesn't work, I copy and paste the text into emacs.  \n\nWhat I would like to do is identify every color git is using for every purpose.  That would let me change, say, all yellow to yellow-on-black.  But I have no way to discover what shows up in yellow, other than intuition.  \n\nThank you for your kind consideration of my suggestion.  \n\n--jkl\n\n"},{"id":"469484","messageId":"xmqqili2rjkn.fsf@gitster.g","threadId":"58994","inReplyTo":"FC7C600C-5D51-4BE0-82BD-9E28C88A1BB8@icloud.com","subject":"Re: report default colors","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-12-23T01:32:24Z","receivedAt":"2022-12-23T01:32:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"James Lowden <james.k.lowden@icloud.com> writes:\n\n> I can get a list of all keys from \"git help\", which is something.\n> But I'm left guessing at which keys control the text on the screen\n> for a given command, and what color they are.\n>\n> In the instant case, \"git push\" was rejected, and the reason is\n> impossible to read because it's in yellow on a light blue\n> background.\n\nInteresting.  I wonder where you are getting the yellow from.  The\nhardcoded default comes from these in builtin/push.c\n\n    static int push_use_color = -1;\n    static char push_colors[][COLOR_MAXLEN] = {\n            GIT_COLOR_RESET,\n            GIT_COLOR_RED,\t/* ERROR */\n    };\n\n    enum color_push {\n            PUSH_COLOR_RESET = 0,\n            PUSH_COLOR_ERROR = 1\n    };\n\nand the push_colors[PUSH_COLOR_ERROR][] is used here\n\n\t...\n\tif (err != 0) {\n\t\tfprintf(stderr, \"%s\", push_get_color(PUSH_COLOR_ERROR));\n\t\terror(_(\"failed to push some refs to '%s'\"), anon_url);\n\t\tfprintf(stderr, \"%s\", push_get_color(PUSH_COLOR_RESET));\n\t}\n\nso I wouldn't be surprised if you see this painted in red, but yellow?\n\nIn any case, there are two things _we_ should do on our end.\n\nOne obviously is to document the default when we document\nconfigurables (e.g. color.push.error only says \"Use customized color\nfor push errors\", but it should say by default it uses red).\n\nThe other is about this part:\n\n> ...  My workaround\n> is to guess what it probably says (probably it says I need to\n> pull).  When that doesn't work, I copy and paste the text into\n> emacs.\n\nNo color is well recognizable on all backgrounds, and people use\ndifferent background, so we need to make sure that our coding\nguidelines tell our developers (1) not to use unusual colors for\ncommon things, and/or (2) make both foreground and background\nconfigurable.\n\n(1) is because if we stick to small number of common colors, it\nwould make it easier for users to find and use a single background\nthat works well with these colors.\n\n(2) is because there will be some users who find whatever common\ndefault colors we use not working for them.  They may need higher\ncontrast between background and foreground, and allowing both be\ntweakable would make it easier for them to find the color pairs that\nwork well.\n\nThanks.\n"}]}