🐛 Ensure that the default rich_markup_mode is interpreted correctly

[svlandeg]

By using Default(DEFAULT_MARKUP_MODE), rich_markup_mode would be a typer.models.DefaultPlaceholder object and comparing it to other literal strings like MARKUP_MODE_RICH would fail. This resulted in flaky behaviour such as reported in #976, where Rich formatting worked fine when specifying it correctly, but the default value (with Rich installed) didn't result in the same behaviour.

This PR fixes that by simply not using Default for this value - there's no real reason to use it anyway, as it's unimportant to the application whether it's a default or a user-set value.

[svlandeg]

The failing coverage test reveals that there are code paths in rich_utils.py that are redundant. They were only taken before by accident, because the comparisons weren't done properly with the Default() object.

In fact, the formatting methods in rich_utils shouldn't be called when rich_markup_mode is None (calling them would be problematic as rich would be imported!). To clarify this in code and to avoid further issues in the future, I've introduced MarkupModeStrict and removed the code paths that are redundant.

[YuriiMotov]

LGTM!

[svlandeg]

Feels to me like the CI is failing due to an unrelated issue - I'll investigate.

[UPDATE]: fixed with #1333

[svlandeg]

on master, this fails with

<typer.models.DefaultPlaceholder object at 0x00000227BB50B130> != rich

[tiangolo]

Awesome, thank you! 🙌

This will be available in Typer 0.20.0, released in the next hours. 🎉