Open balupton opened 5 months ago
The new changes in #253 will make this easy-peasy. The ask
command is where to look. We should roll out --inline
(default), and --no-inline
(required in ask
if not reactive, however as choose
and confirm
use read-key
I don't think reactivity matters for them), for ask
(already done in the PR), choose
and confirm
.
Currently
ask
andconfirm
are rendered inline, yetchoose
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.