Default value gets moved to its own line when the description is 2+ lines long

[apcamargo]

I'm not really sure if this is the expected behavior. If so, please ignore this issue.

When an option descriptions is 2+ lines long, the default value text is moved to an additional line, even when it would fit by the side of the description.

Current behavior:

╭─ Advanced options ───────────────────────────────────────────────────────────────────────────────╮
│  --sensitivity  -s  FLOAT  See there how easy that is. It's amazing what you can do with a       │
│                            little love in your heart.                                            │
│                            [default: 3.5]                                                        │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯

What I expected:

╭─ Advanced options ───────────────────────────────────────────────────────────────────────────────╮
│  --sensitivity  -s  FLOAT  See there how easy that is. It's amazing what you can do with a       │
│                            little love in your heart. [default: 3.5]                             │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯

Vanilla click:

  -s, --sensitivity FLOAT      See there how easy that is. It's amazing what
                               you can do with love.  [default: 3.5]

[ewels]

Oh, that's super weird! Took me a moment to understand what you mean, but I get the same too by changing window width..

One line, default stays inline:

Two lines, default moves onto its own line:

This has got to be something weird with the way I'm using Rich to join these elements together. I'm using a list of renderables (can be different types, eg. Markdown and Text) within a rich Columns object currently:

rich-click/src/rich_click/rich_click.py

Lines 230 to 232 in 66b584c

	# Use Columns - this allows us to group different renderable types
	# (Text, Markdown) onto a single line.
	return Columns(items)

@willmcgugan - any ideas why this behaviour happens? Is there a way to get around this / a better way to join these?

[ewels]

Minimal example with pure rich code:

from rich import print
from rich.console import Console
from rich.columns import Columns
from rich.markdown import Markdown
from rich.text import Text

shortext = Text("Short text")
longtext = Text("Some long text. See there how easy that is. It's amazing what you can do with a little love in your heart. Some long text. See there how easy that is. It's amazing what you can do with a little love in your heart.")
appended = Text.from_markup("[red]APPENDED RED TEXT[/]")
print(Columns([shortext, appended]))
print("-----")
print(Columns([longtext, appended]))

$ python minimal_example.py
Short text APPENDED RED TEXT
-----
Some long text. See there how easy that is. It's amazing what you can do with a little love in your
heart. Some long text. See there how easy that is. It's amazing what you can do with a little love
in your heart.
APPENDED RED TEXT

[ewels]

Sorry, stream of consciousness here. I guess what rich is doing makes sense - they're called columns and you can't split a vertical column if the text wraps over a line.

So to get around this we need a different approach. The columns was suggested here: Textualize/rich#1951 (reply in thread) because using Group always introduces newlines between elements.

We can't just concatenate the string and then format that, because the help text can be one of: raw text, rich markup text, markdown. The default should always be a rich Text because we want consistent styling (and can't easily do [dim] in markdown for example). We can't append Text objects because they could be Markdown.

My best idea currently is to do mytext.append() on purely Text objects if we're not using Markdown (will be the majority of users) and fall back to using a Column if markdown is enabled, with the caveat that we get this edge case ☝🏻