With the new engine-q driven nushell, keybindings to nushell commands for convenience and not destined for the entry in reedline are currently convoluted hacks of several events.
This will affect the state machine of the editor in ways that are hard to recover if you want to actually keep some state from the unfinished manually typed entry:
e.g.
Instead we could have a single event ReedlineEvent::InjectCommand
which will return from the Reedline::read_line with the given command string but keep the current entry plus additional state (up for debate: e.g. history search, active completions etc.) in the reedline object (change on the nushell side necessary to persist that!!!).
Design decision would be how to handle draw position after returning to Reedline::read_line. Either act like a full line was submitted and draw the sent command on submission or try to preserve the prompt position as if nothing happened (tricky if command were to generate output)
With the new engine-q driven nushell, keybindings to nushell commands for convenience and not destined for the entry in reedline are currently convoluted hacks of several events. This will affect the state machine of the editor in ways that are hard to recover if you want to actually keep some state from the unfinished manually typed entry: e.g.
Instead we could have a single event
ReedlineEvent::InjectCommand
which will return from theReedline::read_line
with the given command string but keep the current entry plus additional state (up for debate: e.g. history search, active completions etc.) in the reedline object (change on the nushell side necessary to persist that!!!).Design decision would be how to handle draw position after returning to
Reedline::read_line
. Either act like a full line was submitted and draw the sent command on submission or try to preserve the prompt position as if nothing happened (tricky if command were to generate output)