Add support for help-specific key bindings

[ardnew]

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:

1. The user cannot show/hide individual keybindings. It's a show-all-or-none option per Field.
2. The user cannot adjust the appearance or language used to describe a keybinding.
3. The user cannot add useful help messages as arbitrary text to the help view.
   • This might include mock or pseudo-keybindings:
     • [ ←↑↓→ 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 Field interface:

1. Add a function KeyBindsHelp(_) []key.Binding that returns information used strictly for display of help messages. An argument to this function might distinguish context (e.g., short help versus long help).
   • Use the current function KeyBinds() []key.Binding as the source for actual mapping of keypress events to event handlers processed in the delegate Update routine.
   • This provides the missing functionality to implementations of Field only (either user-defined or huh-packaged).
     • It does not permit users of any Field to modify the help information.
   • This is functionally backwards-compatible, except all current huh.Field implementations will need to define this function as a call to the existing KeyBinds() []key.Binding.
2. Add a callback function 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).
   • If this is never called — the callback is undefined — then the existing behavior remains in effect. That is, the function KeyBinds() []key.Binding is used for both keypress event handling and help view content.
   • This permits any user of any Field to modify the help information (either user-defined or huh-packaged).
   • This is functionally backwards-compatible for similar reasoning as option 1.
   • If this method was added elsewhere (not on the Field interface, maybe to Group or Form), then the callback could be modified to receive the target Field as argument.
     • In this case, this solution could be completely backwards-compatible with no changes to any current huh.Field implementation 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

[bashbunni]

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!

[bashbunni]

Hey, just another note on this - it looks like we do support custom keybinds with WithKeyMap. I haven't used it myself nor do I see any examples on how to use this. You may be able to use NewDefaultKeyMap to create a KeyMap then modify the key.Binding help texts to suit your needs?

Related: #272 & #471

[hxlnt]

@bashbunni One issue with this approach, and partly reiterating what @ardnew said: If I want to show something like "↑/↓ Scroll" to shorten up the help text for up and down, I can cheat it in the huh keymap by changing the key/legend pair for up to "↑/↓," "Scroll" and then hiding the help entry for down. It works OK, except the separator dots (•) for the hidden down entry still render. So, my help footer might look something like this, depending on how many items I have hidden:
↑/↓ • Scroll • • Enter • Confirm •

I believe a compromise that would help with customization while keeping the existing API as-is would be to just not render the • on hidden but active keybindings. That almost seems like a bug, anyway.

On a similar topic, it would be amazing if we could access and change the • through the help Style() to change it if necessary. This is one thing I looked for when trying to see if I could hide the extra • characters that were rendering.

(For context, I ended up replacing the help display with a custom footer that lives in as a huh.Note description because I couldn't tweak the existing help quite enough to my liking and also didn't know how/if I could incorporate a custom Bubbles component without rewriting my entire application.)

[bashbunni]

That most definitely looks like a bug to me. The separators shouldn't show that a help field is hidden, that kind of defeats the purpose 😄 @hxlnt do you mind creating a bug report for this one? I'm not sure what you're doing to hide the help option. Thank you for bringing this up!

I do also like the idea of being able to modify separators. I'll run that one by the team.

[hxlnt]

Got a bit distracted the last few weeks, but yes, I'll build a little repro case and file a bug for this. I can't remember what I was doing to hide the help option, either… probably just passing in a blank string. I'll take a look.

Re: separators--As a user, I'd like to be able to modify keybinding separators with an approach similar to that of multiselect selectors: via a style assignment in huh.Themes. That way, the 95% of people who just go with the default choice of the default theme won't have to do anything, while the 5% of us who like to build custom themes can go in and override the rune along with any other style overrides we have.

Thank you!