Open cactusdualcore opened 1 year ago
My suggestion would be to design the prompt as something like this
[ header ]
[ before ] <input> [ after ]
[ footer ]
or, for multiline input
[ header ]
[ before ] <input>
[continuation] <input>
...
[ footer ]
where header
and footer
are optional multiline strings i. e. Option<&str>
that never spill into the area of user input because they are rendered before and after respectively.
after
is a single-line string rendered after the user input if it does not span multiple lines.
before
is a single-line string on the first line and on all following lines for multi-line input it's continuation
.
This should make painting to screen pretty straightforward I hope, because this now only requires the on screen position of the current prompts position. Then follow these steps to paint
header
to terminalbefore
or continuation
to terminalafter
footer
This is indifferent whether you want to repaint an existing prompt or paint a new one. For the latter use the first line after the last command's response as the new response. This also accounts for #348, because using one of two different prompts for painting easily achieves this functionality.
As this now uses before
and after
this can easily be mirrored in the rendering step for right-to-left prompts.
I should add this is in fact similar to what is done currently. I am asking for well defined and structured behavior.
starship prompt and oh-my-posh prompt are not able to use a transient prompt without this or something similar.
As I already noted here, the current implementation for prompts does not behave well under certain conditions (e. g. if
reedline::prompt::base::Prompt
returns a string containing control characters i. e. line breaks and carriage returns or if ) and it is missing at least a specification for how certain features should work together (e.g. multiline input and completions)Prompt::render_prompt_right
returns a string with line break_(For none of the above have I resized the terminal window)