You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, multiline editing support seems poor. This can be improved by taking inspiration from SLIME.
This probably requires modifying how the history is saved and loaded, because the default way stores history line by line which interferes with multiline inputs.
rlwrap provides a multiline mode; however this ties into an external editor which is what we want to avoid if we want to provide a ipython-like featureful REPL.
The text was updated successfully, but these errors were encountered:
…iro#56)
This commit includes a number of inter-related changes:
- A history file is introduced that stores entries in a string-by-string manner,
similar to SLIME. This easily takes care of inputs containing multiple lines.
- To be able to edit a multiline input, the #\newline and #\return signals are
mapped to MAY-BE-INSERT-NEWLINE, which either inserts a newline character, or
completes the command using rl_newline.
- For correct keyboard navigation in the presence of color codes, prompt ignore
codes defined by libreadline are used.
- Some common keys are bound to commands for visiting previous/next line, and
for previous/next input.
Currently, multiline editing support seems poor. This can be improved by taking inspiration from SLIME.
This probably requires modifying how the history is saved and loaded, because the default way stores history line by line which interferes with multiline inputs.
rlwrap provides a multiline mode; however this ties into an external editor which is what we want to avoid if we want to provide a ipython-like featureful REPL.
The text was updated successfully, but these errors were encountered: