Support NO_COLOR in IO.ANSI

[Łukasz Niemier]

NO_COLOR (https://no-color.org) initiative is an idea to allow user to explicitly opt out from colouring terminal output.

[Chris]

+1

On Mon, Nov 18, 2019 at 5:45 AM Łukasz Niemier <luk...@niemier.pl> wrote:

NO_COLOR (https://no-color.org) initiative is an idea to allow user to explicitly opt out from colouring terminal output.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/cf41b510-0ab4-40cf-8f23-ed53cf12b4f8%40googlegroups.com.

[Rich Morin]

> On Nov 18, 2019, at 03:45, Łukasz Niemier <luk...@niemier.pl> wrote:
>
> NO_COLOR (https://no-color.org) initiative is an idea to allow user to explicitly
> opt out from colouring terminal output.

+1, with comments

Text coloring reduces the contrast, making the text more difficult for the visually
impaired to read. More critically, if coloring is being used to convey distinctions,
this information may be unavailable to users of screen readers.

To cite one example, let's say I'm using the excoveralls package to find out which
lines in a particular file are not covered by tests. I run the command as follows:

MIX_ENV=test mix coveralls.detail --filter lib/info_files/cnt_any.ex

The output lists the file's code, rendering it as follows:

- covered lines in green
- uncovered lines in red
- irrelevant lines in black

However, aside from the colors, there is no way to determine which lines are covered.
A given screen reader may or may not represent the color in a discernible (let alone
useful) fashion.

-r

[Łukasz Niemier]

> Text coloring reduces the contrast, making the text more difficult for the visually
> impaired to read. More critically, if coloring is being used to convey distinctions,
> this information may be unavailable to users of screen readers.

I could be wrong, but in most such cases screen readers will not run as a „real” terminal emulators, but instead will just attach to stdio. So it will work like `foo | cat`, and that behaviour was already handled.

> To cite one example, let's say I'm using the excoveralls package to find out which
> lines in a particular file are not covered by tests. I run the command as follows:
>
> MIX_ENV=test mix coveralls.detail --filter lib/info_files/cnt_any.ex
>
> The output lists the file's code, rendering it as follows:
>
> - covered lines in green
> - uncovered lines in red
> - irrelevant lines in black
>
> However, aside from the colors, there is no way to determine which lines are covered.
> A given screen reader may or may not represent the color in a discernible (let alone
> useful) fashion.

This proposal will not solve such problems, as this will simply disable `IO.ANSI` and will force all output to be „default” (aka, it will not output ANSI escape codes at all). So if you have problem like that, then you should contact library author as this change will make such functionality even less usable.

--

Łukasz Niemier
luk...@niemier.pl

[Rich Morin]

> On Nov 19, 2019, at 08:58, Łukasz Niemier <luk...@niemier.pl> wrote:
>
> ... This proposal will not solve such problems, as this will simply disable `IO.ANSI` and will force all output to be „default” (aka, it will not output ANSI escape codes at all). So if you have problem like that, then you should contact library author as this change will make such functionality even less usable.

Indeed. I was simply pointing out a case where relying on text color makes the output less usable for the visually impaired. FWIW, having received some feedback from a blind friend, I have posted an issue:

reports should not rely only on text coloring
https://github.com/parroty/excoveralls/issues/207

-r