Hi, I’m integrating reeflective/readline into a shell that has multiple “helper” concepts:
- passive hint text based on the current input
- transient forced messages/status updates
- sometimes preview-like content
Right now the single helper surface is useful, but it makes it difficult to keep those concepts distinct.
Current issue
If a shell has:
- passive hint text from the current line
- a transient message from an async event
- preview-ish content
there is no clean public separation between those channels.
That means integrations have to choose who wins, or collapse everything into one helper lane.
Requested API
Something like:
func (rl *Shell) SetHintProvider(func([]rune, int) []rune)
func (rl *Shell) SetTransientHint(text string)
func (rl *Shell) ClearTransientHint()
or any equivalent design that clearly separates:
- passive/background hinting
- explicit one-shot status messaging
Why this matters
This would improve:
- shell UX composition
- async status reporting
- preview/hint coexistence
- frontend parity for shells that already model these separately
Even if preview stays separate in a future API, having hint vs transient-message separation would already help a lot.
Hi, I’m integrating
reeflective/readlineinto a shell that has multiple “helper” concepts:Right now the single helper surface is useful, but it makes it difficult to keep those concepts distinct.
Current issue
If a shell has:
there is no clean public separation between those channels.
That means integrations have to choose who wins, or collapse everything into one helper lane.
Requested API
Something like:
or any equivalent design that clearly separates:
Why this matters
This would improve:
Even if preview stays separate in a future API, having hint vs transient-message separation would already help a lot.