🐛 Fix --help text alignment when using typer.style() in option descriptions#1356
🐛 Fix --help text alignment when using typer.style() in option descriptions#1356mahimairaja wants to merge 12 commits intofastapi:masterfrom
--help text alignment when using typer.style() in option descriptions#1356Conversation
--help text alignment when using typer.style() in option descriptions--help text alignment when using typer.style() in option descriptions
--help text alignment when using typer.style() in option descriptions--help text alignment when using typer.style() in option descriptions
svlandeg
left a comment
There was a problem hiding this comment.
Thanks for the PR @mahimairaja, nice work!
I don't think we had originally envisioned typer.style() to be used as part of the help text of an option, but I can see how this may come up.
On my console, the problem is actually worse when printing the help of the example code on master, I think because it doesn't fully support all formatting. I get this:
With this PR, that becomes
@mahimairaja: can you share a screenshot of the output on your console with this PR? I'd like to see whether the underlined behaviour is in fact displayed correctly on a console that supports it.
Mostly, I think this PR looks good. Just a few thoughts/considerations:
- I don't particularly like hard-coding
"\x1b["inrich_utils.py. Is there a nicer way to check for the ansi escape code? Also I'd like to point out that click actually uses"\033["in https://github.com/pallets/click/blob/main/src/click/termui.py#L512. While they are the same, it might make sense to adhere to the same literal string just for clarity. - We could also consider not having the if-else check on
ANSI_ESCAPE_SEQUENCEand just runText.from_ansialways, but maybe that's computationally unnecessarily expensive for non-escaped strings 🤔 - Finally, while the tests look good, I was wondering if we could add a check for the actual right boundary of
"|". As this was what the report focused on initially, the boundary being misaligned. We could do something like check how many (empty) characters inbetween "This is A" and the next "|"` and then again on the line for B. Maybe it's a bit of a convoluted test, but it would check the correct behaviour.
|
Hi @svlandeg Here is the screenshot before fix: Thanks for the guidance,
Can you please review the changes. |
svlandeg
left a comment
There was a problem hiding this comment.
This looks good to merge to me, I'll pass it by Tiangolo for a final check.
Thanks again, @mahimairaja!
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as spam.
This comment was marked as spam.
|
Thank you @svlandeg! |


Problem
When using typer.style() in help text for CLI options, the help table columns become misaligned. This happens because typer.style() returns a string with ANSI escape codes, and Rich's width calculation includes these control codes, causing incorrect column sizing.
Relevant issue - #1159
Root Cause:
The issue occurs in _make_rich_text() function in rich_utils.py. When help text contains ANSI escape codes from typer.style(), the function was creating a plain Text object that preserved the escape codes as literal characters. Rich's width measurement then counted these control codes, causing misalignment.
Sample Code to reproduce:
Before fix:
After fix:
Testing