I'm assuming you just wanted to add prefix_chars to the constructor for consistency reasons and I'm not missing something else, right?

We do need to pass the prefix chars from the ArgumentParser to the HelpFormatter, so we can distinguish short options from long options.

For example, with this:

import argparse

parser = argparse.ArgumentParser(prefix_chars="-+", color=True)
parser.add_argument("+a")
parser.add_argument("-b")
parser.add_argument("++bleep")
parser.add_argument("-+bloop")
parser.add_argument("-c", "--count")
parser.add_argument("-d", "-+donut")

args = parser.parse_args()

Commenting out line 2735, we don't recognise +a as a short option, don't recognise ++bleep as a long option, and misrecognise -+bloop and -+donut as short options:

With this PR, we get:

Instead of having to do this, couldn't we just set color enabled in the constructor and then also define something like:

def color_me(text, some_color):
  if color:
    return f"{some_color}{text}"
  return text

...Then wrap all of the places we want to colorize? I think that way we could remove the ANSI color stripping and make this a bit easier to follow?

One place we're using this _decolor is in _format_usage for calculating the offsets.

We've already processed all the bits and constructed a string, and added colour relevant for each bit. Here's what the full string looks like:

We then want to post-process it check:

1. will it even fit on one line
2. if not, calculate the offset for each line, based on the offset for the "usage" prefix and prog name:

If we had not already added colour, we would have to somehow figure out where to insert the colour, which I think would be more complicated.

But because we already have colour, we need to make sure the ANSI colour characters aren't included in the width calculations. It seems simpler to use the len() of a colour-stripped string, than the len() of the one with colour.

The other place we#re using _decolor is in calclating the padding of actions in _format_action.

So given desired output like:

We need to calculate the red lines here, the gap between the action_header (for example, x) and the help (for example, the base):

There are three cases:

1. No help: easy, we don't need to calculate a gap. Colour doesn't matter.
2. Long action name: fairly easy, action goes on one line, help on a new line. Help has no colour, we don't need to worry about colour codes when calculating the offset.
3. Short action name: bit harder: action and help fit on one line.

We're using this formatter:

            tup = self._current_indent, '', action_width, action_header
            action_header = '%*s%-*s  ' % tup

%*s means take a min width from the first value -- self._current_indent -- and use it with the next value -- '' -- so just apply the indent. This is okay.

%-*s is similar but means left-align. action_width is the space we have to left align and action_header is something like x. But if we have ANSI codes, we'll count some of these in the width and the gap will be too short.

https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

So we need to calculate this without colour too. Again, some of these strings can have multiple colours applied, so it seems easier to remove the codes when calculating widths, rather than somehow needing to reconstruct the string or re-insert colour.

However, I've noticed I can make this particular change more focused, only for this third case, so I've committed that (c0a0688).