Open BuildStream-Migration-Bot opened 3 years ago
In GitLab by [Gitlab user @cs-shadow] on Jun 29, 2020, 23:03
Thank you for bringing this up. This is probably worth doing from a UX perspective anyway, but the accesiblity issues you mentioned make it even more relevant.
BuildStream already supports user configuration by way of ~/.config/buildstream.conf
. So, it may make sense to add a new option there.
We don't have an existing config section related to the CLI, but it may be worth starting one.
In GitLab by [Gitlab user @rjek] on Jun 29, 2020, 23:13
It's probably worth also noting that emboldening/underlining/obliquing text is unlikely a problem, but trying to communicate data via colour frequency will be.
For my own sanity, it would be delightful if BuildStream could accept the spelling "colour" as a synonym in relation to this functionality.
In GitLab by [Gitlab user @traveltissues] on Jul 1, 2020, 14:10
not directly related but perhaps it's worth having no colour as the default?
See original issue on GitLab In GitLab by [Gitlab user @rjek] on Jun 29, 2020, 10:41
Summary
There is apparently
--no-color
but there is no way to globally disable colour output from, say, a dotfile in my home directory. Colour output is actively unhelpful for the 10% of the population that have some degree of colourblindness.Steps to reproduce
Run any BuildStream command.
What is the current bug behavior?
There is colour.
What is the expected correct behavior?
Method to globally disable colour without having to pass --no-color to every invocation.
Relevant logs and/or screenshots
Possible fixes
Other relevant information