🧙🏻♀️ Bring your dotfile commands and configuration to any shell. Sensible defaults and hundreds of commands preloaded. Supports Bash, Zsh, Fish, Nu, Xonsh, Elvish, Dash, KornShell, macOS, Linux, Windows.
Other
277
stars
21
forks
source link
Suggestion: choose: inline rendering by default #230
Currently ask and confirm are rendered inline, yet choose requires an alt TTY to be established, which looses context.
With the incoming #188, it will be straightforward enough to achieve inline rendering. However, complexity will occur with terminal resizes.
A more intricate version of this recommendation will be to enable more intricate rendering updates, where only the necessary parts of the menu require updating: for typical up/down navigation to a visible item, this will be the bars, and the prior and upcoming cursor limes; navigation to off page items will require rerendering all but the menu question header and menu hints/lengend. Such intricacy may offer a performance boost.
Even without the intricacy of cursor mapped rendering, inline rendering allows context to be maintained if menu size is less than terminal size.
This will be a stretch goal, as the support for question details already allows for context to be copied to the alt tty; and the performance of rendering is already enough for all usage except key repeats.
Furthermore, performance can be better tackled, such as to support key repeats, would be to separate key reading and menu rendering into parallel tasks, which a trivial implementation is that of moving rendering to a background task; note however background tasks do not share scope.
Currently
askandconfirmare rendered inline, yetchooserequires an alt TTY to be established, which looses context.With the incoming #188, it will be straightforward enough to achieve inline rendering. However, complexity will occur with terminal resizes.
A more intricate version of this recommendation will be to enable more intricate rendering updates, where only the necessary parts of the menu require updating: for typical up/down navigation to a visible item, this will be the bars, and the prior and upcoming cursor limes; navigation to off page items will require rerendering all but the menu question header and menu hints/lengend. Such intricacy may offer a performance boost.
Even without the intricacy of cursor mapped rendering, inline rendering allows context to be maintained if menu size is less than terminal size.
This will be a stretch goal, as the support for question details already allows for context to be copied to the alt tty; and the performance of rendering is already enough for all usage except key repeats.
Furthermore, performance can be better tackled, such as to support key repeats, would be to separate key reading and menu rendering into parallel tasks, which a trivial implementation is that of moving rendering to a background task; note however background tasks do not share scope.