How does ansiStylingArgument work

[gizmomogwai]

I updated now to 1.4.1 of argparse. Still my favourite library for commandline parsing!!!
I am having problems with ansiStylingArgument. For me it defaults to autodetect (the documentation says it should be always). And autodetect does not properly detect (I think), by default no colors are emitted when I test against the static auto field that I assign ansiStylingArgument to.

[andrey-zherikov]

For me it defaults to autodetect (the documentation says it should be always)

Could you please point to that statement in documentation? I see 1.x README "By default argparse will try to detect whether ANSI styling is supported" - which means autodetect. The same is for future 2.0 version.

And autodetect does not properly detect (I think), by default no colors are emitted when I test against the static auto field that I assign ansiStylingArgument to.

There is detectSupport() function that does this magic and documentation explains what it does in case if you don't want to look into the source code.

[andrey-zherikov]

FYI when I was adding this feature initially, I looked at different existing libraries for other languages and didn't find a single approach so I combined them in a way that I though make most sense. This doesn't guarantee that detection heuristics works in all cases however so I'm open to improvements.

[gizmomogwai]

One place for example is

argparse/source/argparse/api/ansi.d

Line 13 in b9d971a

.Description("Colorize the output. If value is omitted then 'always' is used.")

if one does not configure the option further it prints ...always....

I think you have the best of all worlds in regards to ansi colors. (textbook quality like https://no-color.org/) Will try to debug, what exactly "does not work" for me.

[gizmomogwai]

I see, that autodetect sees in my case a tty -> so it delivers true, but this is not forwarded to Config.StylingMode.on on my static auto withColors = ansiStylingArgument;variable.
In the documentation you access the static field of your argument struct through the instance variable (not sure if thats the cleanest way todo), but for me both accesses yield the same result -> something falsy -> no colors (unless i set it explicizely to always).

[gizmomogwai]

I could trace the autodetection setting a little further but somehow the Hook
@(Hooks.onParsingDone!(AnsiStylingArgument.finalize)) private struct AnsiStylingArgument is not called.
so config.setStylingMode(detectSupport() ? Config.StylingMode.on : Config.StylingMode.off); still seems to be ok,
cmd.onParsingDone(&config); is pbly also callled, but this basically only calls hooks, and the hook described above is not called for my environment:

# dub --version
DUB version 1.39.0, built on Mar 20 2025
# ldc2 --version
LDC - the LLVM D compiler (1.40.1-git-880d514):
  based on DMD v2.110.0 and LLVM 19.1.7
  built with LDC - the LLVM D compiler (1.40.1-git-880d514)
  Default target: aarch64-unknown-linux-gnu
  Host CPU: (unknown)
  http://dlang.org - http://wiki.dlang.org/LDC

[andrey-zherikov]

One place for example is

argparse/source/argparse/api/ansi.d

Line 13 in b9d971a

.Description("Colorize the output. If value is omitted then 'always' is used.")
if one does not configure the option further it prints ...always....

This means that if value for argument is missed then always is assumed, e.g. --color is the same as --color=always. If command line doesn't have this argument (e.g. no --color) then default value is autodetect.

I could trace the autodetection setting a little further but somehow the Hook
@(Hooks.onParsingDone!(AnsiStylingArgument.finalize)) private struct AnsiStylingArgument is not called.
so config.setStylingMode(detectSupport() ? Config.StylingMode.on : Config.StylingMode.off); still seems to be ok,
cmd.onParsingDone(&config); is pbly also callled, but this basically only calls hooks, and the hook described above is not called for my environment:

This is interesting. I'd expect this unit test to fail in this case but it passes.

Also there is an example that has static auto color = ansiStylingArgument. I checked it as well:

>set NO_COLOR=1
>all_getting_started-advanced.exe aaa --color
Advanced("aaa", "some default value", 0, false, 0, 0, value1, CustomType(nan))
Unparsed args: []
Styling mode: on

[andrey-zherikov]

@gizmomogwai I changed behavior in regards to ANSI coloring: now, Config.stylingMode is not changed and left to be the value that is set at call to CLI... functions. So the proper way to check whether colors should be enabled are with ansiStylingArgument.stdoutStyling and ansiStylingArgument.stderrStyling.
Please let me know if there is anything should be done here.

[gizmomogwai]

How are styling of stdout and stderr controlled from the commandline by default?

[andrey-zherikov]

1. In the beginning, config.stylingMode determines whether styling should be:

• on - enabled
• off - disabled
• autodetect - enabled or disabled based on heuristic

2. If you don't have auto color = ansiStylingArgument in your command then there is nothing that can disable or enable styling at runtime.

3. If you do have auto color = ansiStylingArgument in your command then:

• --color=always enables styling
• --color=never disables styling
• --color=auto enables or disables based on the same heuristic

Note that you can use ansiStylingArgument.stdoutStyling or ansiStylingArgument.stderrStyling any time to check whether styling is enabled even if you don't use auto color = ansiStylingArgument - the latter just adds a way to control styling from the command line.

[andrey-zherikov]

@gizmomogwai Do you still have questions?

[gizmomogwai]

All good ... now I think I understand why there is one commandline argument, but two separate ways to check for colors at runtime.

[andrey-zherikov]

two separate ways to check for colors at runtime

This is mainly for the case when stdout is redirected but stderr is not (see #210).

Closing since there are no more questions.