Standalone Input panic when calling WithWidth about huh HOT 5 CLOSED

You're right. The problem is happening because the input is evaluating its size before theming. I tried to fix it by evaluating the width after theming and it solved the panic, but I found more existing bugs lol

I noticed that WithWidth has no effect when called with Input because form and group override its value by the current terminal width (even in standalone inputs because Input.Run() is just a wrapper for a form with a single group). This also happens to other fields than Input.

I have a solution in mind and can work on the fix if the authors (cc @maaslalani @meowgorithm) haven't yet.

If you need a temporary solution in this version, you can create a form and set the width on it.

huh.NewForm(
	huh.NewGroup(
		huh.NewInput().
			Title("Enter Slack workspace name").
			Value(&workspace).
			Description("Blah"),
	),
).WithWidth(40).Run()

from huh.

Ah interesting, thanks for the detailed bug report @rusq!

@vitor-mariano if I understand your comment correctly this happens only with the single input Run shorthand due to a bug with how form widths / input widths are handled? In that case, we'd be more than delighted to accept a PR for the fix but also happy to fix it ourselves as it seems it's an issue with how the theme/width is being applied.

from huh.

Not really. Let me detail it more.

1. The problems happen regardless of the standalone use. I just emphasized that a standalone input works similarly to a grouped input.
2. I checked the problems with WithWidth happen to other field types.
3. The panic is only one bug related to WithWidth.

Fixing the panic issue, I noticed a second bug. The lib ignores the width of the fields. This happens in two scenarios:

1. When you also set WithWidth in form, it overrides the width of all its children.

   huh.NewForm(
       huh.NewGroup(
   	    huh.NewInput().
   		    Title("Enter Slack workspace name").
   		    Value(&workspace).
   		    Description("Blah").
   		    WithWidth(40),
       ),
   ).WithWidth(60).Run()

   The resulting size will be 60 because form propagates WithWidth to all its children.
2. When you don't set WithWidth in form it propagates the window size to all its children, similarly to when you set WithWidth explicitly:
   https://github.com/charmbracelet/huh/blob/main/form.go#L325-L331

   case tea.WindowSizeMsg:
       if f.width > 0 {
   	    break
       }
       for _, group := range f.groups {
   	    group.WithWidth(msg.Width)
       }

I haven't tested groups yet, but I'm pretty sure the same bug applies.

from huh.

I think the solution is to have two properties in all field types:

1. maxWidth that holds the desired field width.
2. the existing width will be the current rendered width.

To handle these properties, we could have the following functions:

1. A new function Resize(width int) will set the current width without changing the maxWidth.
2. The existing WithWidth(width int) function will set the maxWidth and resize.

This way, the form and groups can control the current width of its fields respecting the maximum width set by the developer.

from huh.

This is fixed by #92

from huh.