Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indentation prompt for multiline edits #598

Open
RubixDev opened this issue Feb 8, 2022 · 3 comments
Open

Indentation prompt for multiline edits #598

RubixDev opened this issue Feb 8, 2022 · 3 comments

Comments

@RubixDev
Copy link

RubixDev commented Feb 8, 2022

I am currently working on creating a REPL for my own language. For multiline editing I just use the matching bracket validator for now, but that puts the cursor to the very front of the next line:

>> fun greet(name) {
    printl('Hello, ' + name + '!')
}
>> 

Comparing this to other REPLs like node or bpython, I would want it to look like this:

>> fun greet(name) {
..     printl('Hello, ' + name + '!')
.. }
>> 

Auto-indentation is not needed, just the placeholder dots in front to align the next lines with the prompt.

I think this would fit best as a config setting like indent_text which is "" by default.

If there already is a way to achieve this, please let me know

@gwenn
Copy link
Collaborator

gwenn commented Feb 9, 2022

No, but there is this old PR.
Maybe you should give a try to reedline and its render_prompt_multiline_indicator.

@RubixDev
Copy link
Author

RubixDev commented Feb 10, 2022

Are there any plans on merging that PR? reedline seems a bit unfinished and less mature to me and I don't really want to switch the whole library for that one feature

@gwenn
Copy link
Collaborator

gwenn commented Feb 10, 2022

Not in its current state.

dmlary added a commit to dmlary/rustyline that referenced this issue Apr 6, 2024
rustyline doesn't currently support changing the prompt while in the
core readline loop.  There are a number of open PRs and issues for this
functionality, but all of them appear to be stalled for more than a
year.

Looking at kkawakam#696 and 4ec26e8, the traditional appoach to this is to
provide a reference to a trait object (`Prompt` or `ToString`), but with
that appoach there's no way to cause the prompt to be redrawn for a
change without user input.  This means for these appoaches the prompt
could change without being displayed to the user.

There's an existing mechanism to allow another async task/thread to push
input into the core readline loop, the `ExternalPrinter`.

In this commit, I expand `ExternalPrinter` to add `set_prompt()`.  With
various plumbing, this function results in `wait_for_input` to return
`Cmd::SetPrompt(String)`.

One of key change here is `State.prompt` changes from `&str`
to `String`.  There is a performance hit here from the copy, but
rustyline would need to prompt and receive input hundreds of times per
second for the copy to have a noticable performance inpact.

Added examples/dynamic_prompt.rs to demonstrate the functionality.

Closes kkawakam#417

Related kkawakam#208, kkawakam#372, kkawakam#369, kkawakam#417, kkawakam#598, kkawakam#696
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants