Replies: 1 comment 4 replies
-
|
Hey @ardnew Huh is meant to be a library with pre-defined components for forms, so we've tried to keep the API as straightforward as possible. I think if you're looking for more customization, then building a Bubble Tea application might be closer to what you're looking for. Are there existing help examples that you think could be improved for Huh to further clarify field usage? Or if you feel really strongly about this, please let us know why you might want more customizability with Huh rather than creating a fully customizable Bubble Tea app. Thank you so much for bringing this up! I'm going to convert this to a discussion so we can keep track of this topic while keeping our backlog clear. Please let me know your thoughts! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Is your feature request related to a problem? Please describe.
The current keybindings displayed in the inline help view are not sufficiently configurable for several reasons:
Field.[ ←↑↓→ move ]versus[ ← left · ↑ up · ↓ down · → right ]Describe the solution you'd like
The two best solutions I can come up with are both modifications to the
Fieldinterface:KeyBindsHelp(_) []key.Bindingthat returns information used strictly for display of help messages. An argument to this function might distinguish context (e.g., short help versus long help).KeyBinds() []key.Bindingas the source for actual mapping of keypress events to event handlers processed in the delegateUpdateroutine.Fieldonly (either user-defined orhuh-packaged).Fieldto modify the help information.huh.Fieldimplementations will need to define this function as a call to the existingKeyBinds() []key.Binding.SetKeyBindsHelp(func (_) []key.Binding)so that the user can provide their own definition of a function that behaves exactly like option 1 above (possibly with the same context argument).KeyBinds() []key.Bindingis used for both keypress event handling and help view content.Fieldto modify the help information (either user-defined orhuh-packaged).Fieldinterface, maybe toGrouporForm), then the callback could be modified to receive the targetFieldas argument.huh.Fieldimplementation required.Describe alternatives you've considered
The addition of dynamic help content is great. The original PR I submitted #127 listed "context-driven help" as the first issue with the current help implementation. The dynamic help changes resolve that issue completely. However, the other items listed above are still applicable.
Additional context
None
Beta Was this translation helpful? Give feedback.
All reactions