dub icon indicating copy to clipboard operation
dub copied to clipboard

Support more values passed to --color(s)

Open nordlow opened this issue 3 years ago • 1 comments

Rust's default build tool, cargo allows the following values passed to --color

        --color <WHEN>          Coloring: auto, always, never

. I find those namings a bit more natural. Shall we support those as aliases aswell?

nordlow avatar Aug 19 '22 09:08 nordlow

No. on and off are simple to remember and to type, and IMO it's better to have one way to do it than a flurry of names.

Geod24 avatar Aug 22 '22 20:08 Geod24

comparing with other linux tools: (checked random dev utilities and https://wiki.archlinux.org/title/Color_output_in_console)

Users of auto, always, never:

  • gdc -fdiagnostics-color=
  • ls --color= (also supports leaving out =value, defaults to always if omitted)
  • diff --color=, diff --colour= (also supports leaving out =value, defaults to auto if omitted)
  • grep --color= (also supports leaving out =value, not specified what that means though)
  • ld.lld --color-diagnostics= (also supports leaving out =value, defaults to auto if omitted)
  • other tools unrelated to development I found working this way:
    • cal (--color defaults auto)
    • ip (-color defaults always)
    • dmesg (--color` defaults auto)

Simple flags:

  • less --use-color (unsure what it means, as this tool only works with a tty, it pretty much maps to "auto", because otherwise it just outputs the file as-is)
  • npm --no-color (means never)
  • pip --no-color (means never)
  • tsc --pretty (means always in my test, but actual meaning / behavior is undocumented)
  • msbuild -clp:DisableConsoleColor (means never) and msbuild -clp:ForceConsoleColor (means always)

Boolean values:

  • ldc2 --enable-color=0 or 1 (means always, also supports leaving out =value, but that's undocumented usage - means 1 then)
  • dmd -color=on (always) or off (never) or auto (also supports leaving out =value, means on if omitted)

Other:

  • git uses color.ui, color.<subcomponent> config with true (= always) / false / auto
  • npm also has npm config set color <value> with true (= auto) / false / always

Just with development tools they look pretty even, but most GNU and linux utilities seem to use the auto, always, never scheme.

Additionally looking at the other tools, it seems sometimes unclear what even simple booleans mean (does on mean always or auto?) and in any way it's unclear if omitting values means auto or always. The unclear behavior with the tools that use these values makes it even more unclear for tools using booleans.

So I think it makes sense if we switch to that as well (can keep on and off supported for backwards compatibility) because it looks like auto, always and never is actually more widely used, thus probably easier to remember by most developers.

WebFreak001 avatar Dec 15 '22 10:12 WebFreak001