This is just a POC, it needs tests, docs, etc.
Note that there are other issues with unicode handling, textwrap will split multiple-code-points glyphs.

>>> textwrap.wrap("Cafe\u0301 is good", width=4)
['Cafe', '́ is', 'good']

Sorry but we should not change textwrap now. It's a major change and this may break more than one code (it's also a new feature so we cannot fix 3.14 directly). I've had this kind of issue with Sphinx recently: sphinx-doc/sphinx#13762 where 0-width glyphs are not handled correctly by textwrap. I will close this PR and suggest that you first focus on fixing argparse itself for the colors if you want.

Oh actually the patch is quite simple. However as it's a new feature we cannot backport it =/ so we need to think of a solution that can be backported. If it's not possible I would suggest:

• Leaving it like this in 3.14.
• Fix it in 3.15 with the new feature you suggested.

If the PR is not ready, I will make it a draft.

Thanks for the reply! I was not thinking about backporting the changes to 3.14 to be honest.

The cleanest solution would be to incorporate a complete unicode handling with a technique similar to wcwidth, that would allow for proper wrapping of all glyphs.

That being said, as this would be indeed a major addition to stdlib, a good first step might be to add the new option to ignore_ansi_escape to textwrap, as this is a much smaller change, and backward-compatible as well, if it defaults to False. My initial PR was a draft already, but I can finish it if you feel this is OK.

Well.. looks like the current tests are broken which is not good. I need to think about the changes to textwrap. Ideally, we should be able to specify a len function instead. That's what I did when I wrote my Sphinx' fix. We have a custom _wrap_text. But OTOH, I think we should do something in textwrap to make it extensible or subclassable so that the logic of detecting a word & length is actually overridable. For now, let's hold a bit so that you are not working for naught.

@serhiy-storchaka Do you think it makes sense to make textwrap more customizable in how it detects the different words and splits. We can already do it through a regex but we should also be able to provide a custom length function to have a better tweakable behavior. This is just an idea and this really needs more polishing especially with how we would like to provide such interface if this makes sense.

Sorry, the draft contained a bug due to a copy paste error, I just pushed a fix.

See #56708, and also #56777 and #68853. I think that they would also resolve this issue.

#28136 seems to me the simplest solution to fix this, more extensible than this PR, avoids introducing ANSI escape code knowledge in textwrap module.
So I can close this if #28136, or a similar solution, is merged.

This PR is stale because it has been open for 30 days with no activity.

Closing this since #154634 was merged.